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Foreword 


The GEOSCIENCE LASER ALTIMETER SYSTEM (GLAS) is the primary instrument for 
the ICESat (Ice, Cloud and Land Elevation Satellited laser altimetry mission. ICESat was the 
benchmark Earth Observing System (EOS) mission for measuring ice sheet mass balance, 
cloud and aerosol heights, as well as land topography and vegetation characteristics. From 
2003 to 2009, the ICESat mission provided multi-year elevation data needed to determine ice 
sheet mass balance as well as cloud property information, especially for stratospheric clouds 
common over polar areas. It also provided topography and vegetation data around the globe, 
in addition to the polar-specific coverage over the Greenland and Antarctic ice sheets. 

This is the final version of GLAS Science Algorithm Software Detailed Design (GSAS-DD) 
document. This document is developed under the structure of the NASA STD-2100-91, a 
NASA standard defining a four-volume set of documents to cover an entire software life 
cycle. Under this standard a section of any volume may, if necessary, be rolled out to its own 
separate document. This document is a roll-out of the detailed design within the Product Spec- 
ification Volume. 

This document was created by the GLAS Science Algorithm Software (GSAS) Development 
Team in support of B. E. Schutz, GLAS Science Team Leader for the GLAS Investigation. 
This work was performed under the direction of David W. Hancock, III, who may be con- 
tacted at (757) 824-1238, David.W.Hancock@nasa.gov (e-mail), or (757) 824-1036 (FAX). 
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Section 1 


Introduction 


1.1 Identification of Document 

This document is identified as the GLAS Science Algorithm Software (GSAS) Detailed 
Design Document. This is the final release of this document. 

1 .2 Scope of Document 

The GLAS I-SIPS Data Processing System, show in Figure 1-1, provides data processing and 
mission support for the Geoscience Laser Altimeter System (GLAS). I-SIPS is composed of 
two major software components - the GLAS Science Algorithm Software (GSAS) and the 
Scheduling and Data Management System (SDMS). GSAS processes Level-0 satellite data 
and creates EOS Level 1 A/B and 2 data products. SDMS provides for scheduling of process- 
ing and the ingest, staging, archiving and cataloging of associated data files. This document 
describes the detailed design of the GSAS component. 
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Figure 1-1 I-SIPS Software Top-Level Decomposition 
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1.3 Purpose and Objectives of Document 

This document describes the detailed design of GSAS. It contains descriptions, flow charts, 
data flow diagrams, and structure charts for each major component of the GSAS. 

The purpose of this document is to present the detailed design of the GSAS. It is intended as a 
reference source which would assist the maintenance programmer in making changes which 
fix or enhance the documented software. 

1.4 Document Organization 

This document's outline is assembled in a form similar to those presented in the NASA Soft- 
ware Engineering Program [Information Document 2.3a]. 

1.5 Document Change History 


Document Name: GLAS Science Algorithm Software Detailed Design Document 

Version Number 

Date 

Nature of Change 

Version 0 

August 1999 

Original Version 

Version 1 

November 2000 

Revised for VI software. 

Version 2 

November 2001 

Revised for V2 software. 

Version 2.2 

July 2002 

Revised for V2.2 software. 

Version 3.0 

October 2002 

Revised for V3.0 software. 

Version 4.0 

August 2004 

Revised for V4.0 software. 

Version 5.0 

October 2005 

Revised for V5.0 software. 

Version 6.0 

August 2012 

Revised for V6. 0.1 software. 
Final edition. 
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Section 2 


Related Documentation 


2.1 Parent Documents 

Parent documents are those external, higher-level documents that contribute information to 
the scope and content of this document. The following GLAS documents are parent to this 
document. 

a) GLAS Science Software Management Plan (GLAS SSMP), NASA/TM- 1999-208641/ 
Version 3/Volume 1, August 1998, NASA/GSFC Wallops Flight Facility. 

b) GLAS Science Data Management Plan (GLAS SDMP), NASA/TM-1999-208641/ 
Version 4/Volume 2, July 1999, NASA/GSFC Wallops Flight Facility. 

c) GLAS Science Software Requirements Document (GLAS SSRD), NASA/TM-200 1 - 
208641 /Version 2.1/Volume 3, November 2000, NASA/GSFC Wallops Flight Facility. 

d) GLAS I-SIPS Software Architectural Design Document, Version 2.0, October 1998, 
NASA/GSFC Wallops Flight Facility. 

2.2 Applicable Documents 

Applicable documents include reference documents that are not parent documents. This cate- 
gory includes reference documents that have direct applicability to, or contain policies bind- 
ing upon, or information directing or dictating the content of this document. The following 
GLAS, EOS Project, NASA, or other Agency documents are cited as applicable to this docu- 
ment. 

a) Data Production Software and Science Computing Facility (SCF) Standards and 
Guidelines, 423-16-01, January 14, 1994, Goddard Space Flight Center. 

b) EOS Output Data Products, Processes, and Input Requirements, Version 3.2, Novem- 
ber 1995, Science Processing Support Office. 

c) NASA Earth Observing System Geoscience Laser Altimeter System GLAS Science 
Requirements Document, Version 2.01, October 1997, Center for Space Research, 
University of Texas at Austin. 

d) The Algorithm Theoretical Basis Document for Level 1A Processing, NASA/TM- 
2012-208641 / Volume 5, June 2012, NASA Goddard Space Flight Center, et al. 

e) The Algorithm Theoretical Basis Document for the GLAS Atmospheric Data Products, 
NASA/TM-20 12-208641 / Volume 6, July 2012, NASA Goddard Space Flight Center, 
et al. 

f) The Algorithm Theoretical Basis Document for the Derivation of Range and Range 
Distributions from Laser Pulse Waveform Analysis for Surface Elevations, Roughness, 
Slope, and Vegetation Heights, NASA/TM-20 12-20864 1/Volume 7, August 2012, 
NASA Goddard Space Flight Center, et al. 
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Related Documentation 


g) The Algorithm Theoretical Basis Document for the Atmospheric Delay Correction to 
GLAS Laser Altimeter Ranges, NASA/TM-20 12-208641 /Volume 8, NASA Goddard 
Space Flight Center, et al. 

h) The Algorithm Theoretical Basis Document for Tidal Corrections, NASA/TM-2012- 
208641 /Volume 9, Scripps Institution for Oceanography, et al. 

i) The Algorithm Theoretical Basis Document for Precision Orbit Determination, 2012, 
University of Texas Center for Space Research, et al. 

j) The Algorithm Theoretical Basis Document for Precision Attitude Determination, 
2012, University of Texas Center for Space Research, et al. 

k) The Algorithm Theoretical Basis Document for Laser Footprint Location ( Geoloca- 
tion) and Surface Profiles, 2012, University of Texas Center for Space Research, et al. 

l) GLAS Standard Data Products Specification - Level 1, NASA/TM-20 13 -208641 /Vol- 
ume 13, NASA Goddard Space Flight Center, et al. 

m) GLAS Standard Data Products Specification - Level 2, NASA/TM-20 13-208641/ 
Volumel4 , NASA Goddard Space Flight Center, et al. 

n) GLAS Standard Data Products Specification - Data Dictionary, NASA/TM-20 13- 
208641/Volume 15, NASA Goddard Space Flight Center, et al. 

o) GSAS User’s Guide, NASA/TM-2013-208641/Volume 17, NASA Goddard Space 
Flight Center, et al. 

2.3 Information Documents 

The following documents are provided as sources of information that provide background or 
supplemental information that may clarify or amplify material presented in this document. 

a) NASA Software Documentation Standard Software Engineering Program, NASA- 
STD-2 1000-91, July 29, 1991, NASA. 

b) Science User s Guide and Operations Procedure Handbook for the ECS Project, Vol- 
ume 4: Software Developer s Guide to Preparation, Delivery, Integration and Test 
with ECS, Final 205-CD-002-002, August 1995, Hughes Information Technology Cor- 
poration. 

c) GLAS Science Algorithm Software (GSAS) User s Guide, NASA/TM-2013-208641/ 
Volume 17, NASA Goddard Space Flight Center. 

d) GLAS Standard Data Products Specification - Level 1, NASA/TM-2013-208641/Vol- 
ume 13, NASA Goddard Space Flight Center. 

e) GLAS Standard Data Products Specification - Level 2, NASA/TM-2013-208641/ 
Volume 14, NASA Goddard Space Flight Center. 

f) GLAS Standard Data Products Specification - Data Dictionary, NASA/TM-2013- 
208641 /Volume 15, NASA Goddard Space Flight Center. 
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g) Data Production Software, Data Management, and Flight Operations Working Agree- 
ment for AIRS, AMSU-A and MHS/AMSU-B, January 1994, NASA Goddard Space 
Flight Center,. 
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Section 3 


Design Issues 


3.1 Requirements 

GSAS was designed with specific and generic requirements in mind. These requirements may 
be found in the GLAS Software Requirements Document. Several of the more critical require- 
ments are listed here: 

• The software will be designed for maximum portability and code-reuse. 

• When possible, science algorithm subroutines should be coded in a manner to allow 
for re-use outside of GSAS. Subroutines, for example, should pass data via arguments 
and not rely on the presence of global product data structures. 

• All Level 1 and Level 2 standard data products will be produced in an integer-binary 
format 

• Input and output products will be delimited by UTC start and stop times. 

• Full processing history will be available via metadata. 

• Standardized messaging and error-handling using local ancillary fdes will be available 
to all subprocesses. 

• Changeable parameters will be defined in local ancillary files. 

• Implement the capability to fully and partially process and reprocess data with several 
different scenarios, including: 

One processing string that starts with GLAS telemetry data (GLAOO) as input to 
create all output L1A products (GLA01-03). 

One processing string that starts with GPS-specific GLAS telemetry data 
(GLAOOxx) as input to create all output L1A GPS product (GLA04GPS). 

One processing string that starts with L1A altimetry data (GLA01) as input to cre- 
ate an output waveform product (GLA05). 

One processing string that starts with a waveform product (GLA05) and two atmo- 
sphere products (GLA09 and GLA11) as input to create output elevation products 
(GLA06, 12,13,14,15). 

One processing string that starts with LI A atmosphere (GLA02) input and pro- 
duces output atmosphere products (GLA07,08,09,10,11). 

One processing string that starts with a waveform product (GLA05) as input to 
produce an output elevation product (GLA06). 

3.2 Single vs. Multiple Executables 

In the early designs of GSAS, the team incorporated a single-executable strategy. This 
approach changed in V2 to focus on multiple PGEs (Product Generation Executables). A PGE 
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is an executable program which performs a specific function. The ‘core’ PGEs perform spe- 
cific portions of the GLAS data processing and generate deliverable GLAS Data Products 
(Products). The core PGEs are accompanied by a set of utility PGEs which perform such func- 
tions as creating ancillary data files, performing quality assurance and generating browse 
products. 

3.3 Software Reuse 

The team recognized that there would be several task-specific PGEs which interface with data 
created by the I-SIPS data processing system. In order to effect the reuse of this software, the 
GLAS Team implemented major components and subsystems as shared libraries. These 
libraries are generic such that they may be used by several different GSAS components with- 
out modification. It is intended that associated utility software will be written to use these 
libraries in order to maximize code-reuse and ease coding and maintenance tasks. 

3.4 I/O and Unit Conversion 

The software reuse approach was especially important in the design of the GLAS Product 
input/output routines. The I/O routines were designed in a modular fashion to make them 
available for use in software outside of the core PGEs. All input/output statements are imple- 
mented in product-specific subroutines. All data transformations (scaling from integer to 
floating point and vice versa) are implemented in product-specific routines. This insures con- 
sistency in the conversion process methodology and forces a great deal of granularity in the 
design. Additionally, care was taken to minimize the number of support routines required by 
the I/O conversion processes in order to maximize the potential for software reuse. 

3.5 Reprocessing and Pass-Thrus 

Reprocessing and partial-processing requirements dictated great care in the design of GSAS. 
In addition to executing all science algorithms consecutively, it is required that GSAS be able 
to run selected science algorithms with varying input data types. Processing with a selected set 
of science algorithms and products is defined as a specific processing “scenario”. The soft- 
ware not only must be able to execute selected science algorithms, it is required to rewrite 
selected products, partially replacing selected data. An example of this is replacing the orbit 
on the primary elevation product (GLA06). 

In order to accommodate the reprocessing requirement, the GSAS processing software is 
designed to use “pass-thru” data management. The “pass-thru” concept dictates that common 
data are passed from lower-numbered products to higher-numbered products on input. In the 
design, the products can be input, output or both. Science algorithms are required to use input 
data from the highest-numbered product possible and pass computed data to requisite higher- 
numbered products. 
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3.6 Data Buffering 

Data buffering is a fairly complex process. GSAS is required to process data one second at a 
time without buffering, except in two cases: the Atmosphere subsystem and the LI A L_Att 
processing. 

The Atmosphere subsystem ATBD has required that data be buffered to twenty seconds. This 
buffering has been designed into the Atmosphere subsystem, such that other portions of the 
software are not impacted by the added complexity. However, during the implementation it 
was decided to minimize the buffering complexity by adopting a constraint such that GLA08- 
1 1 will not be processed independently of one another. This constraint somewhat limits the 
granularity of re-processing, but was approved by the GLAS Change Control Board as an 
acceptable trade-off. The buffering concept is fully documented in the Atmosphere section. 

L_Att processing is complicated by the issue of time delays aboard the spacecraft. All data for 
one second of APID 1984 (PRAP) are not contained within a single one second packet. In 
order to precisely time-align the relevant data, the LI A subsystem uses a 6-record double- 
buffered algorithm to match the relevant LRS and 1ST data to the APID 19 shot times. Given 
the potential for missing data, some valid PRAP data may be lost if its corresponding APID 19 
data are missing. 
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Design Overview 


4.1 GSAS Design Overview 

The GSAS processing system is designed to be both efficient and flexible. The system is 
designed for operational flexibility, considering data availability constraints and reprocessing 
requirements. In order to meet these requirements, the design of the software consists of up to 
four functional layers which work together to perform the data processing function. See Fig- 
ure 4-1 . From the bottom up, the first layer is a set of generic library routines which form the 
foundation of the software. The second layer is comprised of the science algorithm subsystem 
libraries, which perform the actual transformation from raw data into GLAS products. The 
third layer is the subsystem managers, which control the execution of the science algorithms. 
The fourth and final layer is made of four core PGEs, executable “shells” which surround the 
subsystem managers and provide standardized I/O, error handling, and initialization. 


LOproc 

PGE 


L1A PGE 


Atmosphere PGE 


Altimetry PGE 


Utilitiy 

PGEs 


3 

Level 1A 
Manager 

Level 1 B and 2 
Atmosphere Manager 

Level IB Waveforms 
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Manager 

Level 1A Library 

Atmosphere Library 

Waveforms Library 

Elevation Library 

Science Algorithms 

Science Algorithms 

Science Algorithms 

Science Algorithms 






Common Libraries 


Figure 4-1 GSAS Layers 

Success of this design, coding standards, and implementation was proven when this code was 
ported from a big-endian HP/UX to little-endian Linux environment without significant 
rework. 

4.2 PGEs 

The GSAS PGEs are: 

• GLAS_LOproc, which processes GLAS LO data; 

• GLAS_L1A, which executes the Level 1A (LI A) subsystem; 

• GLAS_Alt, which executes the Waveforms (WF) and Elevation (Elev) subsystems; 

• GLASAtm, which executes the Atmosphere (Atm) subsystems; 

• GLAS_Meta, which produces inventory metadata files; 

• and Other PGEs which perform utility functions. 

The first four PGEs are “core” PGEs. Figure 4-2 is a very simplified data flow diagram which 
shows the relationship between GSAS PGEs and GLAS data products. Many ancillary files 
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and utilities are required for GSAS processing. These have been omitted in order to show an 
overview of GSAS. Create_GLA16 was a HDF product creator which was designed and 


GLAOO 

APIDs 




Figure 4-2 Simplified GSAS Data Flow Diagram 
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tested, but no never approved for production. 

4.3 Files 

Throughout this document, files are referenced as one of two types: GLA or ANC. GLA files 
are, for the most part, fixed-length, integer-binary format Product files containing Level 0-2 
GLAS science data. GLA files are both input for and output to GSAS PGEs. ANC files are 
requisite multi-format ancillary files. Some are supplied by the science team; others are 
received from external data providers. The prime difference between GLA and ANC files are 
that GLA files are deliverable data products, whereas ANC files are not. These files are 
detailed in the GLAS Data Management Plan and GLAS Data Product Users Guide. 

4.4 Science Algorithms 

GSAS science algorithms are published in the Algorithm Theoretical Basis Documents 
(ATBD) provided by the GLAS Science Team. The resulting code is grouped into four ATBD 
subsystems separated by scientific discipline. These subsytems, science data products, and the 
science algorithm libraries are listed in Table 4-1. 


Table 4-1 Subsystem, Libraries and Products 


Subsystem 

Library 

Output Products 

LI A Processing 

11 a Jib 

G LA0 1-04 

Waveform Processing 

wfjib 

GLA05 

Atmosphere Processing 

atm Jib 

GLA07-11 

Elevation Processing 

elevjib 

GLA06.12-15 


The subsystems are designed such that data required by each subsystem is available from a 
product (data file) written by a preceding subsystem. As a result there is very little data depen- 
dence between the subsystems. 

Associated with each ATBD subsystem is a corresponding Subsystem Manager. These Man- 
agers use control input to determine what processes to execute within the subsystem and what 
data to write. 

4.5 Utilities 

In addition to the core PGEs, there are several utility PGEs which perform various data trans- 
formations and computations. These utilities use the same core library routines as the core 
PGEs. There are two main types of utilities: 

• Utilities executed infrequently - based on static or near-static input. Examples are: 

Reference orbit groundtrack file creation 

Create DEM file 

Ingest and reformat geoid file 
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Create regional masks data set 
Create global and regional load tide grids 

- Assist in verifying product content 

- Assist in processing spacecraft test data 

• Utilities executed routinely as part of daily production processing. Examples are: 
Calculate granule start times and ascending node times 
Create level 0 index files 
Subset Meteorological data files 
Create Browse products 

- Validate ANC32 GPS files 
Verify QA products 
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Foundation Libraries 


The base level of GSAS software is packaged as a collection of core library routines. These 
libraries are coded in a generic manner such that all GSAS software can make use of the func- 
tionality. This design maximizes code reuse and all inherent advantages. 

Library code is implemented in separate directories and grouped by functional area. A single 
makefde in each library directory will compile the code into a dynamically-linked shared 
library. A “master” makefile will compile all the libraries and create the final binaries in one 
step. See the GSAS User Guide for details on file layout and compilation specifics. 

A hierarchy of dependencies exist between the libraries. The order in which libraries are com- 
piled is important since libraries may depend upon other libraries for support routines. This is 
not relevant if the developer uses the supplied cascading makefile, but the developer should be 
aware that these dependencies exist. The dependency structure is illustrated in Table 5-1. 


Table 5-1 Library Inter-dependencies 


To build... 

The following libraries are required... 

platformjib 

<none> 

time Jib 

platformjib 

cntrljib 

platformjib 

errjib 

platformjib, 

math Jib 

platformjib 

ancjib 

platformjib, cntrljib, errjib, mathjib 

prodjib 

platformjib, cntrljib, errjib 

filejib 

platformjib, cntrljib 

geojib 

platformjib, cntrljib, errjib, mathjib, ancjib 

execjib 

platformjib, cntrljib, errjib, mathjib, ancjib 


5.1 The Platform Library (platformjib) 

platformjib is the most basic library in the foundation libraries. Nearly all GSAS code uses 
routines from the platform library. The purpose is to provide consistent datatypes across all 
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GSAS software, to provide a place for storing constants, and to provide compiler-dependent 
F90 routines. Modules included in the platform_lib are described in Table 5-2. 


Table 5-2 platformjib Modules 


Module 

Description 

c_compare_mod 

Generic functions write differences (if any) between arguments. 

const_atm_mod 

Defines atmosphere-related constants. These constants are initialized as 
parameters or have values read from an ancillary file. 

const_elev_mod 

Defines elevation-related constants. These constants are initialized as 
parameters or have values read from an ancillary file. 

const_glob_mod 

Defines common global constants. These constants are initialized as 
parameters or have values read from an ancillary file. 

constjlajmod 

Defines LIA-related constants. These constants are initialized as parame- 
ters or have values read from an ancillary file. 

const_util_mod 

Arguments for utility programs 

const_wf_mod 

Defines waveform-related constants. These constants are initialized as 
parameters or have values read from an ancillary file. 

kindsjmod 

Defines the basic GLAS datatypes, for example 2 byte integers, 4 byte 
integers, 4 byte reals, and 8 byte reals. 

Inblnk 

Returns position of the last non-blank character in a string. Provided for 
those F90 implementation which do not support this function. 

types_mod 

Defines common complex GLAS datatypes, including structures, (depreci- 
ated) 

ve rs_p 1 atf o r m_m od 

Version information for the library. 


5.2 The Control Library (cntrMib) 

cntrllib provides control-related functions to GSAS software. Components include routines 
for parsing “keyword=value” formatted files, string functions, user-interface functions, and a 
common file control datatype. Modules included in the cntrMib are described in Table 5-3. 


Table 5-3 cntrl lib Modules 


Module 

Description 

centertext_mod 

Centers a text string within an 80 character padded string. 

compare_kval_mod 

Compares keyvalues against label. Strings are converted to uppercase 
before a comparison is performed. This ensures that keyvalues are not 
case-sensitive. 

doubleline_mod 

Prints an 80 character double line to the supplied 10 unit. 

fStruct_mod 

Defines a generic GLAS file info structure. Also contains routines to initial- 
ize and print a file info structure. 
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Table 5-3 cntrMib Modules (Continued) 


Module 

Description 

find_keyword_mod 

Searches for the provided keyword within a set of provided values. 

getans 

Reads a character of input, and validates that input from a list of accept- 
able values. 

gsas_toupper 

Replacement subroutine for “toupper” which conflicted with an HDF-EOS 
routine of the same name. Converts alpha characters to upper case. 

keyval_mod 

Defines a keyword=value datatype. 

multimenu_mod 

Returns a set of logicals based on user menu selection 

parse_keyval_mod 

Parses keyword and value components from argument string. 

read_line_mod 

Reads a line of input, skipping comments (#). 

singleline_mod 

Prints an 80 character single line 

strcom press 

Compresses multiple spaces to a single space within a string 

strtrim 

Trims white space from around a text string 

tolower 

Converts alpha characters to lower case 

writebanner_mod 

Prints banner at start of processing 

vers_cntrl_mod 

Version information for the library. 

writebanner_mod 

Prints banner at start of processing 


5.3 The Error Library (errjib) 

err_lib provides status and error-related functions to GSAS software, err lib is designed to 
read messages from an ancillary file. Errors and status messages (henceforth referred as 
errors) are reported to an output ancillary file (if available) and to standard output (stdout). 
Errors have negative numeric designations; status messages have positive designations. Errors 
are designed to be configurable as to the severity of the error and frequency of printout. 

Modules included in the err lib are described in Table 5-4. 


Table 5-4 err lib Modules 


Module 

Description 

ANC06_mod 

Writes an error message to the ANC06 unit in a standard format. In order 
to avoid cyclic dependencies, ANC06_mod will not use GLAS Error_mod 
upon encountering an error (since GLAS Error WILL use ANC06_mod). A 
result code will be returned, but the caller must act upon it, if necessary. 

ErrDefs_mod 

Defines the GSAS error data structure. 

ErrorBootjmod 

Initializes the error to generic values before the ancillary error file is read. 
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Table 5-4 errjib Modules (Continued) 


Module 

Description 

Errorlnit_mod 

Perform initializations for the Error and Status function by extracting the 
error variables from argument error strings. This routine does dynamic 
array allocation so that the number of errors is not fixed. A routine is also 
provided to print the parsed errors. 

GLAS_Error_mod 

Receives an error number as an argument, looks up the error, writes the 
error to ANC06 and stdout, and returns a severity code to the calling pro- 
cess. 

WriteError_mod 

Formats an error and writes to ANC06 and stdout. 

compare_err 

Error comparison routine for qsort. 

vers_err_mod 

Version information for the library. 


5.4 The Math Library (mathjib) 

math lib provides standard math routines to GSAS software. Components include bilinear 
interpolation and matrix multiplication. Modules included in the cntrl_lib are described in 
Table 5-5. 


Table 5-5 math lib Modules 


Module 

Description 

c_bilin_interp_mod 

Calculates the value of properties at a point by doing a bilinear interpola- 
tion of the 4 points straddling it. 

c_linear_smooth_mod 

Implements a smoothing function over a linear array 

c_matmul_mod 

Returns the product of two matrices. 

c_matrix_smooth_mod 

Implements a smoothing function over an n x m matrix array 

c_minmaxmean_mod 

Provides routines to compute statistics for the given parameter. 

c_quadratic_mod 

Solves a quadratic equation up to rank of 4. 

conversions_mod 

Provides routines to convert between and swap different datatypes. 

onepass_avg_mod 

One-pass algorithm for accumulating data needed to compute the stan- 
dard deviation without the problems that can be caused by roundoff errors 
when using the simpler though numerically equivalent equation. 

polar_stereographic_m 

od 

Polar-stereographic coordinate transform module. 

w_add2hst_mod 

Computes histogram bin index. 

vers_math_mod 

Version information for the library. 

w_add2hst_mod 

Computes histogram bin index. 
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5.5 The Ancillary Library (ancjib) 

anc_lib provides routines to read and parse GLAS ancillary files. GSAS ancillary files are of 
various formats. Some ancillary files contain relatively static data while others contain 
dynamic data. 

Modules included in the anc lib are described in Table 5-6. 


Table 5-6 anc lib Modules 


Module 

Description 

anc01_met_mod 

Reads meteorological (met) header data into a global data structure. 
Structures exist for two met header files. Also verifies the existence of 
associated met data files and provides a routine to write the met header 
information to stdout. 

anc04_quat_mod 

Definitions for ANC04 Quarternions Matrix. 

anc07_mod 

Parses an ANC07 file and calls specific routines to read each parsed sec- 
tion. 

anc07_atm_mod 

Reads and parses atmosphere-related constants from a constants ancil- 
lary file. 

anc07_glob_mod 

Reads and parses global constants from a constants ancillary file. 

anc07_elev_mod 

Reads and parses elevation-related constants from a constants ancillary 
file. 

anc07_err_mod 

Reads and parses error constants from a constants ancillary file. 

anc07_glob_mod 

Reads and parses global constants from a constants ancillary file. 

anc07J1a_mod 

Reads and parses LI A-related constants from a constants ancillary file. 

anc07_stat_mod 

Reads and parses status constants from a constants ancillary file. 

anc07_wf_mod 

Reads and parses waveform-related constants from a constants ancillary 
file. 

anc08_pod_mod 

Contains Precision/Predict Orbit Determination (POD) record length and a 
flag to determine if POD is of predicted or precision quality. 

anc09_pad_mod 

Contains Precision Attitude Determination (PAD) record length, public 
data structure, availability flag, and routines to initialize and read PAD 
records. 

anc12_dem_mod 

Contains Digital Elevation Model (DEM) record lengths, unit number, pub- 
lic LandMask, and routines to read, calculate and print the DEM values. 

an c13_geoid_mod 

Contains the Geoid record length, public grid and routines to initialize and 
read the geoid. 

anc16_ltide_mod 

Contains the record length and unit of the load tide ancillary file. 

anc17_otide_mod 

Contains the record length and unit of the ocean tide ancillary file. 

ancl 8_stdatm_mod 

Reads and stores the standard atmosphere ancillary file. 
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Table 5-6 ancjib Modules (Continued) 


Module 

Description 

anc22_track_mod 

Read and store anc22 type NOSE information 

anc23_nose_mod 

Read and store anc23 type NOSE information 

anc25_gpsutc_mod 

Reads and parses the GPS/UTC time conversion file. 

anc27_surftype_mod 

Reads and stores the surface type file. 

anc29_index_mod 

Reads, writes, and stores the GLAS_L0proc index file. 

anc30_aer_mod 

Reads and stores the global aerosol map ancillary file. 

anc31_trop_mod 

Reads and store the global aerosol trop map ancillary file. 

anc32_gps_mod 

Reads, writes and stores the GLAS_L0proc GPS correlation file. 

anc33_utc_mod 

Reads the UTC time conversion file. 

a n c3 5_ozo n ejnod 

Reads and stores the ozone file. 

anc36_atm_mod 

Reads the atmosphere calibration file. 

anc38_msf_mod 

Reads the atmosphere multiple scattering factor file. 

anc41_ephim_mod 

Contains definitions for JPL ephemeral file. 

anc45_meta_mod 

Contains definitions and routines for ANC45 product metadata templates. 

anc46_meta_mod 

Contains definitions and routines for ANC46 anc metadata templates. 

anc47_pds_mod 

Contains definitions and routines for PDS/EDS construction record. 

anc51_srtm_mod 

Equivalent to SRTM tracker_reader module, which provides access soft- 
ware for SRTM track files. 

anc52_corr_mod 

Reads and stores load range correction tables. 

anc53_aerosol_mod 

Reads and stores the aerosol data. 

anc54_dem_mod 

Reads and stores hi-rest ICESat DEM file. 

anc55_mss_mod 

Reads and stores mean sea surface file. 

anc56_pt_mod 

Reads and stores the Pole Tide file. 

anc57_bathymetry_m 

od 

Reads and stores the bathymetry file. 

anc58_gtrk_mod 

Reads and stores the reference groundtrack files. 

anc59_ptg_mod 

Reads and stores the pointing table. 

anc_hdr_mod 

Reads and writes the limited header portion of selected ancillary files. 

c_calcsatCorr_mod 

Calculates saturation corrections and sets the correction flag. 

inst_state_mod 

Contains routines for instrument state change detection. 
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Table 5-6 ancjib Modules (Continued) 


Module 

Description 

anc_hdr_mod 

Reads and writes the limited header portion of selected ancillary files. 

vers_anc_mod 

Version information for the library. 


5.6 The File Library (filejib) 

file_lib provides standard routines to open and close GSAS files using the passed file info 
structures. Modules included in the file lib are described in Table 5-7. 


Table 5-7 file lib Modules 


Module 

Description 

cksum.c 

Calculates POSIX checksum (C) 

CloseFile_mod 

Closes a file. 

OpenFlnFile_mod 

Opens an input file. 

OpenFOutFile_mod 

Opens an output file. 

parse_fname_mod 

Parses the standard GSAS file naming convention. 

vers_file_mod 

Version information for the library. 


5.7 The Time Library (time_lib) 

time lib is the only significant portion of GSAS source code implemented in C. It is an imple- 
mentation of a GSFC time library and used by GSAS with little to no modification. time_lib 
provides routines for converting to/from various time formats. Modules included in the 
time lib are described in Table 5-8. 
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Table 5-8 timejib Modules 

Description 

Has routines for the following functions: 

-add two arrays holding times into a third array 
-add a yymmdd and a day 
-add a yyyymmdd and a day 

-find the difference between two yymmdd's in days and seconds 
-find the difference between two yyyymmdd's in days and seconds 
-convert between yyyymmdd, hms, mjd, fday, and mjdsec 
-convert yymd fday to J2000 days and fday 
-convert J2000 days and fday to yymd fday 
-convert yymmdd or yyymmdd to yyyymmdd 
-convert yyyymmdd to yymmdd 
-convert mjd to yymmdd 
-convert mjd to yyyymmdd 
-convert yymmdd to mjd 
-convert yyyymmdd to mjd 
-convert hhmmss to fday 
-convert fday to hhmmss 
-convert fday to hm with decimal seconds 
-convert yyyymmdd to ddd 
-convert yyyymmdd to yyyyddd 
-convert yyyyddd to yymmdd 
-convert mjd to mjdsec 
-convert mjdsec to mjd 
-convert mjdsec to sec 
-check if yyyy is a leap year 

Converts between J2000 seconds and 19 character ASCII representa- 
tions. 

Version information for the library. 

5.8 The Product Library (prodjib) 

prodlib provides routines to read, write, and convert GLAS products. The routines (and con- 
cepts) are fully described in the Common Functionality section. Modules included in the 
prod lib are described in Table 5-9 (where xx = a GLAS product number [01-15]). 


Table 5-9 prodjib Modules 


Module 

Description 

GLA00_mod 

Contains routines for reading GLA00 APIDs. 

GLAxx_mod 

Contains routines for reading and writing GLAxx product data structures. 

GLAxx_alg_mod 

Contains public data structures for GLAxx algorithmdata and routines to 
initialize and print the data structure. 


Module 

dateinterface 


j2000to1 9char_mod 
vers time mod 
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Table 5-9 prod_lib Modules (Continued) 


Module 

Description 

G L Axx_p rod_mod 

Contains public data structures for GLAxx product data and routines to ini- 
tialize print the data structure. 

GLAxx_scal_mod 

Contains public data structures for GLAxx scale data and routines to ini- 
tialize and print the data structure. Also contains routines to convert from 
product units to algorithm units and the reverse. 

GLAxx_Pass_mod 

Passes common data from a lower-numbered product/algorithm data 
structure to higher-numbered product/algorithm data structures. 

GLAxx_print_mod 

Prints product data structures in integer/floating point format (as opposed 
to hexadecimal). 

GLAxx_flags_mod 

Contains routines for packing and unpacking GLAxx flags. 

common_flags_mod 

Contains routines for packing and unpacking common flags. 

common_hdr_mod 

Contains routines to read and write common elements of the product 
headers. 

get_numhdrs_mod 

Searches through product headers to find number of headers. 

prod_def_mod 

Contains record sizes for all GLAxx products. 

qap_version_mod 

Write qap version to qap file 

vers_prod_mod 

Version information for the library. 


5.9 The Exec Library (exec_lib) 

execlib contains high-level routines which are common to each of the GSAS PGEs. Much of 
the code which was in the original single executable has been modified and moved into this 
library. Modules included in the exec_lib are described in Table 5-10. 

Table 5-10 fexec lib Modules 


Module 

Description 

C_CalcNrg_mod 

Calculate the energy of the received and transmitted pulses. Here 
because it is shared between two subsystems. 

CheckOutput_mod 

Loops through the file type structures to determine if any more output is 
requested. 

CloseFiles_mod 

Closed any opened files, based on file control structure. 

CntlDefs_mod 

Initializes common control definitions. 

Mainlnit_mod 

Performs common initialization functions. 

MainWrap_mod 

Performs common wrap-up functions. 

OpenFiles_mod 

Opens requested files, based on file control structure. 

ReadAnc_mod 

Reads ancillary files, based on file control structure. 
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Table 5-10 fexecjib Modules (Continued) 


Module 

Description 

ReadDatajnod 

Reads data from opened files in a time-synchronous fashion. 

StdCntl_mod 

Parses common control instructions from a Control files. 

Write_An cVe r_mod . 

Writes ancillary file version info to ANC06. 

Write_LibVer_mod 

Writes library version info to ANC06. 

C_Retre i ve_H i Res_D 
EM_mod 

Retrieves surface elevation from high resolution DEM data source 

c_nose_mod 

Contains routines to assigning data to NOSE rectangles. 

check_out_time_mod 

Utility function for verifying continuity of time on output data products. 

check_recndx_mod 

Utility function for comparing start/stop times of granules. 

com_hdr_update 

Updates the header data structures for product files. 

fCntl_mod 

Defines file control structures. 

get_fileindex_mod 

Utility function for determining file type from filename. 

get_secstart_mod 

Finds start of control file section. 

parse_filecntl_mod 

Parses file information from control file. 

passid_mod 

Holds passid information parsed from the control file. 

pastendofperiod_mod 

Utility routine to determine if current time is past the end of the period. 

set_inst_state_mod 

Sets the Instrument State flag. 

vers_exec_mod 

Version information for the library. 
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Section 6 

GSAS Core PGEs 


6.1 Function 

GSAS core PGEs reside at the uppermost level of the GSAS data processing software. These 
executables are responsible for controlling the data processing. They perform initializations, 
set constants, read ancillary data, handle data input and output, and provide a global error 
facility. All GSAS core PGEs are structured the same, since they are basically instantiations of 
a reference PGE model. As such, this section will document that reference design rather than 
each individual PGE. Changes from this reference design will be documented in the section 
for each specific PGE. 

6.2 Requirements 

Most requirements are PGE-specific and defined in the appropriate PGE section. There are 
several high-level requirements which the core PGE approach satisfies. 

• A control file will be used to control processing and specify input and output files. 

• Files will be opened and closed within the PGE and its associated managers. Process- 
ing routines will not open or close files. 

• Common values will be used to designated missing or invalid data on GLAS products. 

• A common error/status facility will be used. 

• All error/status messages will be logged and written to a log file (ANC06). 

• Version information will be logged. 

• Summary statistics such as number of records read/written and the number occur- 
rences of each type of status/error will be computed and logged. 

• Reference data subject to change will be stored and retrieved from change-controlled 
ancillary files (ANC07). 

6.3 Approach 

• The system start and stop will be controlled by each respective executable at the 
uppermost level. 

• Processing will be performed one record at a time, though individual subsystems may 
buffer multiple records before processing. Multiple input products will be time-syn- 
chronized. (GLAS_LOproc is an exception to this.) 

• Control flags will determine which subsystem or subsystem process will be executed. 

• Input and output data will be delimited by start and stop times. 

• The system will provide for partial processing and reprocessing scenarios. 
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• In order to maximize code reuse and ease-of-use, PGEs will be designed to use stan- 
dard facilities provided by the GSAS libraries. 

6.4 Design 

Figure 6-1 shows the top-level structure chart of a generic GSAS core PGE. The basic algo- 
rithm for a GSAS PGE is: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (Print_Cntl) 

• Read static ancillary files (ReadAnc) 

• Write version info (Write_LibVer, Write_AncVer) 

• Until all specified data are processed... 

Read Data (ReadData) 

Process Data (Manager) 

- Write Data (Manager) 

• Close all files and generate summaries (Main Wrap) 

The main routine for a GSAS PGE is local to the PGE - in other words, the source code is 
located within the PGE subdirectory, not within a library. The main PGE routine will perform 
other functions besides calling the appropriate subroutines. Code within the main routine will 

• Initialize flags indicating start and end of processing 

• Write its version number 

• Write any associated subsystem version info 

• Set a status code indicating success or failure on program termination 

Additionally, in the case of a PGE with no Manager, subroutine calls to processing code and 
actual data transformations may be located within the main routine. 

Although not shown on the structure charts, nearly every GSAS routine calls glas error, the 
standard error facility, to report error and status messages. 

Subsequent sections will identify and explain the functionality of each of the structure chart 
elements. 


Version 6.0 


Page 6-2 


March 2013 



GSAS Core PGEs 


The GLAS Science Algorithm Software Detailed Design Document 



Figure 6-1 Top-Level Structure Chart 

6.4.1 Mainlnit 

Mainlnit is an element of the exec_lib. The Mainlnit structure chart is show in Figure 6-2. 
Mainlnit performs the following functions: 

• Initializes the ANC06 output channel to stdout in order to display initialization error 
messages to the console. 

• Initializes the default error subsystem, (error boot) 

• Initializes the standard file control structures. (fCntl lnit) 

• Initializes Product scaling values. (GLAxx_scal_init) 

• Initializes Algorithm data structures to default values. (GLAxx alg init) 

• Initializes Product data structures to default values. (GLAxx_prod_init). 
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Figure 6-2 Mainlnit 


6.4.1. 1 Error_Boot 

The error boot routine is part of the errorlib. It initializes the glas_error facility with a “boot- 
strap” set of error codes in order to facilitate error handling during the initialization and file- 
opening phases of execution. These “bootstrap” errors will be overwritten once the ANC07 
error file is read later in execution. 

6.4.1. 2 fCntIJnit 

fCntllnit is within the fCntl_mod entry of the exec_lib. fCntl_mod contains both file-related 
parameters and subroutines. These parameters include: 

• Maximum number of file types 

• Maximum number of files per type 

• Numeric indices for each filetype 

• ASCII representation for each filetype 

• Control file name 

• An structure of arrays containing information regarding each file used in processing. 

fCntl lnit initializes the file information structures with information regarding direct/format- 
ted access, record lengths, multi-granule flags, granule index, and current record number. 

This module is very important to a maintenance programmer if he should need to add a new 
file type to the GSAS software. Be aware, that the order of the definitions within fCntl is crit- 
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ical. Changes in one internal data structure should be mirrored by like changes within the 
other associated data structures. Also be aware that grouping of the file types is important. 
New products should be added within the product subsection (GLA01-GLA16). Likewise, 
new APIDs should be added within the APID subsection (APID12-APID1984). 

6.4.1. 3 GLAxx_scal_init, GLAxx_prod_init, GLAxx_alg_init 

These routines are elements of the prod Jib. There exist a set of these routines for each GLAS 
product. The seal Jnit routines initializes a product-specific data structure to scale values 
which are used when converting between product and algorithm units. The prod init and 
alg init routines initializes the respective product and algorithm data structures to initial and / 
or invalid values. 

6.4.2 eCntMnit 

eCntlJnit is a routine within eCntl_mod, which is local to each PGE. eCntl_mod contains the 
local execution flags which the Manager uses to control process flow. eCntlJnit initializes 
these flags. These flags are later set by GetControl based on values within the control file. 

6.4.3 GetControl 

GetControl is a routine local to each specific PGE. This routine reads and parses the control 
file. It’s structure chart is in Figure 6-3. GetControl performs the following functions: 

• Initializes standard control structures (init_StdCntl) 

• Opens the control file. (OpenCF) 

• Reads the control file until it finds the specified section header. 

• Reads the section contents, parsing local and standard (parse_StdCntl) control file 
entries. 

• Sets control flags based on control file entries. 

• Closes the control file at the end of the section. 

• Performs sanity-checking. 



OpenCF Parse_StdCntl 


Figure 6-3 GetControl 
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Of particular importance in the routine is the fact that it parses control entries which are spe- 
cific to each individual PGE. Execution and option flags are defined in a local eCntl module. 
GetControl sets these flags based on parsed control values. If a maintenance programmer 
needs to add another control flag to a PGE, he must make changes in both eCntl mod and 
GetControl. 

6.4.3.1 lnit_StdCntl 

InitStdCntl is a subroutine within the StdCntl_mod of the exec_lib. ft initializes the text rep- 
resentation of standard (i.e.: common to all PGEs) control file elements. 

6.4.3.2 OpenCF 

OpenCF is a subroutine within the StdCntl mod of the exec_lib. ft uses a system call to get 
the value of the control file argument. Platform-specific defines are used here to set the correct 
position of the argument within the argument list. After getting the name of the control file, 
OpenCF opens the specified file and scans the file for the start of the specified section. If the 
control file cannot be opened, a fatal error is returned to the calling process. 

6.4.3.3 Parse_StdCntl 

Parse StdCntl is a subroutine within the StdCntl_mod of the exec_lib. ft takes control file 
entries common to all PGEs and parses them, filling the appropriate data structure. In the case 
of INPUTFILE and OUTPUTFILE controls, the routine will attempt to decode the filetype 
from the filename and fill the appropriate file control structure. 

6.4.3.4 Sanity_Check 

Sanity Check is a subroutine within the local GetControl module, ft will examine the parsed 
execution flags and file control structures in order to determine if the control file specifica- 
tions are valid for the specific PGE. Each PGE has a set of pre-determined rules which dictate 
what combination of flags and files are appropriate for the defined execution scenarios. Errors 
will be generated if Sanity_Check finds a problem with the control file configuration. 

6.4.4 OpenFiles 

OpenFiles is an element of the exec lib. ft opens the first granule of each filetype specified in 
the control file. The files are opened as direct or formatted based on information in the file 
control structure. Normally, OpenFiles assigns a unit to each file it opens and reassigns that 
same unit to each subsequent granule of that particular filetype. However, in the case of multi- 
file granules (indicated by a flag in the file control structure), OpenFiles will assign unique 
units to each file of the first granule and open all files of the first granule. Those files which 
are not opened are checked for existence and readability. 

6.4.5 PrintCntl 

PrintCntl is a subroutine of the StdCntl module within the exec_lib. It writes the control file 
contents to the ANC06 log file. 

6.4.6 WriteJJbVer 

Write LibVer is an element of the exec lib. It writes foundation library version information to 
the ANC06 log file. 


Version 6.0 


Page 6-6 


March 2013 



GSAS Core PGEs 


The GLAS Science Algorithm Software Detailed Design Document 


6.4.7 ReadAnc 

ReadAnc is an element of the exec_lib. It calls subroutines within the anc lib to read all 
requested static ancillary files. The contents of these files are kept in core memory, and, by 
definition, only read once per execution. 

Some special cases exist within ReadAnc: 

• If available, the first two ANC01 header files are read via ReadAnc, but subsequent 
ANC01 header files are read in a time- synchronized fashion within ReadData. Subsys- 
tem-specific MET routines read the actual MET science data. 

• Precision Orbit Determination files (ANC08) are not read, but the number of POD 
files available are counted and this count is stored in a global variable within 
anc08_pod_mod for later use. A POD data structure is initialized based on the number 
of files available. 

• Precision Attitude files (ANC09) are via a special routine which converts the provided 
GPS time to UTC time. A flag is set which can be used to determine if valid PAD data 
exist. 

• ANC29 and ANC32 files are read into memory and sorted to account for potential 
PDS boundary problems. The ANC29.32 design is documented in more detail in the 
GLAS_LOproc and GLAS L1A sections. 

6.4.8 Write_AncVer 

Write AncVer is an element of the execlib. It writes any version information regarding ancil- 
lary files which were read to the ANC06 log file. 

6.4.9 ReadData 

ReadData is an element of the exec lib. It calls subroutines to read one second of requested 
dynamic ancillary and product data in a time-synchronized fashion. It also seemlessly handles 
end-of-granule conditions and sets file-specific data availability flags in the appropriate file 
control structure. Figure 6-4 shows the structure chart for ReadData. 

Data are read in a logical order which allows lower-numbered products to pass values forward 
to data structures of higher-level products. See Section 6.5 for more information regarding the 
“pass-thru” concept and product/algorithm data conversion. 
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Figure 6-4 ReadData 

The time-synchronization methodology used by ReadData is rather complex. The following 
algorithm will attempt to describe the procedure: 

• Save time and index of last data read. 

• Initialize global time and index to invalid 

• Loop through each input file type we are to synchronize 

Set data time and index to invalid 

Get the current granule index of the current filetype 

Set the readnew flag to false. 

Loop within the current granule of the current filetype unless the file is not avail- 
able or we reach EOF 
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- Read a data record (ReadRecord) 

- Cycle if EOF 

Cycle if data time < specified start time 

Set sync time to data time of record we just read 

Exit Interior Loop 

- We exit exterior loop when we have a sync time and data time >= sync time +- 
limit. If we exceeded the limit, decrement the counter and fill the record with inva- 
lids. Write error message regarding data gap. 

• Check all input files from which we sync for EOF. If all EOF, then set end-of-process- 
ing flag and return to calling routine. 

• If requested, synchronize ANC09 with data time. 

• If requested, synchronize ANC01 with data time. Since we keep 2 ANC01 header files 
in memory, move the 2nd to the 1st and read a new one into the 1st until data are syn- 
chronized. 

In addition, since some GSAS records contain data whose duration exceeds one second, there 
is a algorithm used to determine when a record of a particular data type has exceeded it’s 
“validity”. This allows for the integration of one second data with multi-second data records. 
Once the defined period of validity has passed, ReadData replaces the current data with new 
data, or, if no data can be synchronized, invalid data to account for gaps. 

Note that custom read subroutines are required for APIDs 19, 25, 35 and 55. These are 
required since these APIDs have data misalignments while prevent them from being read in 
the standard way. 

6.4.9.1 ReadRecord 

ReadRecord is an internal subroutine to ReadData. It calls file-specific routines to read one 
second of the requested data type. ReadRecord will seemlessly move across multiple gran- 
ules, if necessary. If unsuccessful in reading the requested record, it will set the specific data 
structure to invalid values and return a flag indicating failure. 

6.4.9.2 next_granule 

next_granule is an internal subroutine to ReadData. It closes the current granule and open the 
next, if available. File control structures are set to indicate success or failure. 

6.4.9.3 InvalidRec 

InvalidRec is an internal subroutine to ReadData. It calls file-specific routines to set the data 
structures of the target file to invalid values. 

6.4.10 Managers 

Managers are routines local to each specific PGE. Managers control and execute process-spe- 
cific tasks. The use of a Manager routine in a PGE is entirely optional. The purpose of a man- 
ager is to provide a software layer between the fairly generic main routine and the task- 
specific subroutines or subsystem libraries. A good rule of thumb is to use a Manager for com- 


March 2013 


Page 6-9 


Version 6.0 



The GLAS Science Algorithm Software Detailed Design Document 


GSAS Core PGEs 


plex processing jobs, but to simply insert code into the main routine for relatively simple 
tasks. 

6.4.11 MainWrap 

Main Wrap is an element of the exec_lib. This routine is called just before the end of execution 
to close any open fdes and write summary data to ANC06. This summary data includes: 

• The number of each type of status message encountered. 

• The number of each type of error message encountered. 

• The number of records read for each input file used. 

• The number of records written for each output file created. 
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Section 7 

Common Functionality 


GSAS code was designed for maximize software reuse. The foundation libraries provide a 
code base which the developer can use to ensure consistency and maximize code reuse among 
GSAS PGEs. The libraries provide standardized routines for such things as parsing control 
fdes, reading constants files, and reporting error/status messages. By following GSAS con- 
ventions, PGEs can basically take advantages of these services “for free.” The previous sec- 
tion introduced the components of the foundation libraries. This section describes the 
functionality provided by these libraries. 

7.1 Control File Parsing 

GSAS PGEs are designed to use Control files as the interface with the user (or controlling 
process). Control files provide dynamic control information to PGEs. 

PGEs are designed to take the name of the control file as a command-line argument during 
each invocation of the PGE. Most PGEs should terminate with a fatal error if the command- 
line argument is missing, the specified file does not exist, or the file is unreadable. The excep- 
tion to this rule is when the PGE provides a rudimentary user-interface when invoked without 
a control filename. GLAS_Reader and GLAS_APID, utilities, are currently the only instances 
of this exception. 

GSAS control files are designed to be part of a larger control file used by one or more PGEs 
(or even PGEs outside of GSAS!). The larger control file includes sections which identify the 
PGE that will perform the task requiring the inputs contained in the section. Each section is 
bounded by an "=" sign in column 1 , followed by the PGE name that requires the control 
inputs. Exact section names will be shown in the PGE-specific control file section of this doc- 
ument. 

All GSAS control files are created in standard GSAS “keyword=value” format. This format is 
text-based and consists of a line containing a keyword/value pair delimited by an equal sign 
(=). The ordering of the keywords is not relevant but should follow a convention for consis- 
tency. Multiple instances of certain keywords are allowed. The keyword is not case sensitive. 
Spaces are allowed, but not required. Comment lines must be prepended by a “#” character. 
The keyword is limited to 255 characters; the value is limited to 255 characters. 

PGE sections within a control file contain both co mm on and process-specific information. 
The process-specific portions of control files will be provided within the documentation for 
each specific PGE. This section will document the common elements of the control files. 
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Within a control file section, some information is required, other is optional. Required single- 
instance keywords (Table 7-1) include: 


Table 7-1 Required Single-Instance Keywords 


Keyword 

Value 

TEMPLATE_NAME= 

Name of the control file template. 

EXEC_KEY= 

Unique (per day) execution key 

DATE_GENERATED= 

Date the control file was generated. 

OPERATOR= 

Operator who generated the control file. 

PGE_VERSION= 

Version number of the target PGE. 

Optional multiple-instance keywords (Table 7-2) include: 

Table 7-2 

Optional Multiple-Instance Keywords 

Keyword 

Value 

PASSID= 

Pass-related information 

TRACK= 

Track [number start_time stop_time] 

INPUT_FILE= 

Input file [filename start_time stop_time] 

OUTPUT_FILE= 

Output file [filename start_time stop_time] 

WRITE_CONST= 

Signals that the specified constants should be written to ANC06. 


7.1.1 PASSID Specification 

A PASSID section is required in the control file when creating GLA products. There should 
be one instance of the following keyword/values for all tracks which fall within the minimum/ 
maximum time of the data being processed. This information is required for GLAS L1A, 
GLAS Alt, and GLAS_Atm. This information is NOT required for GLAS_LOproc or other 
utilities. 

PASSID=revolution_num<sp>pas- 

sid<sp>start_time<sp>stop_time<sp>equator_crossing_lon<sp>no 
se_path_number . 

Descriptions of the PASSID elements are provided in Table 7-3. 


Table 7-3 PASSID Control Line Elements 


Element 

Description 

revolution_num 

integer, containing the auto-incrementing rev number. 

passid 

11 -byte character, further described below. 

start_time 

double-precision float, containing J2000 UTC time in seconds. 
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Table 7-3 PASSID Control Line Elements (Continued) 


Element 

Description 

stop_time 

double-precision float, containing J2000 UTC time in seconds. 

equator_crossing_lon 

float, containing the equator crossing longitude. 

nose_path_number 

integer, containing the NOSE path number. 


The eleven-byte passid field will be treated as follows: prkkccctttt. Descriptions of each ele- 
ment are provided in Table 7-4. 


Table 7-4 passid Field Description 


Field 

Description 

P 

repeat ground track phase (integer, length=1) 

r 

reference orbit number (integer, length=1) 

kk 

instance (integer, length=2) 

ccc 

cycle (integer, length=3) 

tttt 

track (integer, length=4) 


7.1.2 Input/Output File Specification 

Input and Output files are required to be designated using the GSAS-standard naming conven- 
tion defined in Appendix A. The type of each file specified is determined by parsing specific 
components of the filename which are required by all of the naming methods defined in the 
specification. These common components of all filenames are: 

HHHxx_mmm . . . f f . eee 

(where: HHH is the type identification, xx is the type id number, mmm is the release number, 
ff is the file sub-type, and eee is the file extension.) 

GSAS software uses the type identification, the type id number and the file sub-type to deter- 
mine what type of file is specified in the control file. The filetype-parsing routines are not 
case-sensitive when determining the type of file specified. However, the filenames are case- 
sensitive during file opening and creation. 

All files are required to be delimited by start and stop times. These times are floating point 
values specified on the control line as J2000 time in seconds. On both input and output, 
records are skipped until the time in the current record is greater than or equal to the specified 
start-time and less than or equal to the specified stop-time. Static ancillary files are required to 
have start-times and stop-times present for consistency, but these are currently ignored. 

The general formats for an input and output file specifications are: 

INPUT_FILE=f ile_name<sp>start_time<sp>stop_time 
OUTPUT_F I LE = f i 1 e_name < sp > s t ar t_t ime < sp > s t op_t ime 
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Additionally, GLA product fde entries should contain segment and version information. This 
information is specified in the format: 

INPUT_FILE=f ile_name<sp>start_time<sp>stop_time<sp>gran_rel_ 
num< sp >gr an_ve r_num< sp >gr an_s egment 

OUTPUT_FILE=f ile_name<sp>start_t ime<sp>stop_t ime<sp>gran_rel 
_num<sp>gran_ver_num<sp>gran_s egment 

Segment and version information fields are described in Table 7-5. 


Table 7-5 File Segment and Version Fields 


Field 

Description 

gran_rel_num 

granule release number (CCB controlled, mmm in filenaming convention.) 
Character max length of 20. 

gran_ver_num 

granule version number (Auto-incrementing, nn in filenaming convention). 
Character max length of 20. 

gran_segment 

orbit segment of the granule (if more that 1 segment, use 0). Character 
max length of 1 . 


Files with INPUT_FILE and OUTPUT_FILE keywords must be listed in chronological order 
based on start and stop times. The start time of one file may overlap the stop time of another. 
In this case, data within the overlapping range will be written to the first file and not the sec- 
ond. 

7.1.3 Input Data Time Selection 

As referenced in the Control File section, all files are required to be delimited by start and stop 
times. PGEs which support time selection will skip that data which are outside the limits 
defined by start and stop times. This data will be read, but not processed. Additionally, given 
the case of multiple input files of the same type, the PGE will seemlessly skip from one file to 
the next when all data from the current file has been read (or skipped via time selection). 

Certain input ancillary files do not support input time selection but require, none the less, start 
and stop times in their control file entry. This was a design decision intended to promote con- 
sistency within the control file content. The start and stop times for these ancillary files should 
encompass the entire time range of the input data. 

7.1 .4 Output Data Time Selection 

As with input files, all output files are required to be delimited by start and stop times on their 
control file entry. PGEs which support time selection will not write that data which are outside 
the limits defined by start and stop times. Additionally, given the case of multiple output files 
of the same type, the PGE will seemlessly skip from one file to the next when the current data 
time falls outside the range of the current output file. It is important to note that input data 
time selection and output data time selection are completely independent of one another. 
There is, however, a practical relationship between the two, since output data for a particular 
time cannot be written if no input data for that time are read (or specified). 
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7.1.5 Execution scenarios 

Most core PGEs permit multiple execution scenarios. Certain sets of computations have been 
grouped together by the software designers. Execution of these sets can be specified via spe- 
cific execution flags with the PGE control file. The detailed documentation for each PGE 
specifies what execution flags are available and the processes they control. Additionally, there 
are dependencies between input file type, output file type, and the execution flags. These 
dependencies define execution scenarios, which will be described in the respective PGE 
detailed documentation. 

7.2 ANC07 Constants Files 

ANC07 files are used to provide GSAS with static, change-controlled parameters provided by 
the Science Team and used during processing of GLAS data. These parameters were carefully 
selected such that these parameters could be modified without forcing a recompilation of the 
processing software. It is critical that these files are tightly change-controlled since unap- 
proved modification could result in erroneous or inconsistent data being generated during the 
creation of the GLAS Products. 

There are several types of ANC07 files. These types include a global constants file, an error 
file, and constants files specific to each of the science algorithm categories. 

Constants files are specified as input files within a particular PGE’s control file. The global 
constants file and the error constants file are required for all executables. 

GSAS ANC07 files are delimited by section identifiers which differ (by design) from control 
files section identifiers. Each section is bounded by the section name and an "=". The section 
delimiters are defined as follows: 

BEGOFSTATU S= 

...Status section contents... 

ENDOFSTATU S= 

BEG OF ERROR= 

...Error section contents... 

ENDOFERROR 

BEG OF GLOBALS= 

...Global constants section contents... 

ENDOFGLOBALS 

BEG_OF_ATM= 

...Atmosphere constants section contents... 

ENDOFATM 

BEG_OF_ELEV= 

...Elevation constants section contents... 

END OF ELEY 
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BEG_0F_L1A= 

...L1A constants section contents... 

ENDOFL1A 

BEG_OF_UTIL= 

...Utilities constants section contents... 

ENDOFUTIL 

All GSAS ANC07 files are created in standard GSAS “keyword=value” format. This format 
is text-based and consists of a line containing a keyword/value pair delimited by an equal sign 
(=). The ordering of the keywords is not relevant but should follow a convention for consis- 
tency. Multiple instances of keywords are not allowed. The keyword is not case sensitive. 
Spaces are allowed, but not required. Comment lines must be prepended by a “#” character. 
The keyword is limited to 255 characters; the value is limited to 255 characters. 

7.3 Invalid Values and Error/Status Reporting 

This section documents the use of standardized methods of dealing with invalid data and 
error/status conditions. 

7.3.1 Invalid Values 

Not all data received from GLAS will be suitable for science processing. In addition, given 
the nature of the raw telemetry packets, some data may be missing. The concept of an “invalid 
value” is used to signify that data is invalid or missing and should not be used for processing. 
Invalid values are datatype-specific values which are defined in the GLAS global constants 
module. These variables are assigned to Product variables in order to indicate invalid or miss- 
ing data. These values are defined in Table 7-6. Great care should be taken to avoid using an 
invalid value during a calculation. Additionally, great care must be taken by both the program- 
mer and data user to determine if the variable in question is defined as potentially invalid. One 
can only consider data to be invalid if the product documentation defines that variable as 
potentially invalid and the variable has the appropriate invalid value respective to its datatype. 


Table 7-6 Invalid Values 


Datatype 

Invalid Value 

1 byte integer 

127 

2 byte integer 

32767 

4 byte integer 

2147483647 

4 byte real 

3.40282E+38 

X7F7FFFFF 

8 byte real 

1 .79769309486231 6E+308 
X7FEFFFFFFFFFFFFF 
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7.3.2 Exit Status 

All GSAS PGEs are required to return an exit status indicating success or failure of the pro- 
cess. See Table 7-7. This status is returned through an operating system call and can be que- 
ried by other operating system processes. The supported exit status codes are gFATAL=3 and 
gN O_ERROR=0 . 


Table 7-7 PGE Exit Status Codes 


Value 

Description 

0 

Process completed with no errors. 

3 

Process failed. 


Note that the Exit status was designed to return numbers consistent with the GSAS error/sta- 
tus reporting facility’s error severity values. However, the exit status codes are but a subset of 
the GSAS error severity codes. 

7.3.3 Error and Status Reporting 

GSAS uses a common error/status reporting facility. This ensures that error/status reporting is 
handled in a consistent manner throughout the software. This facility is based on the ANC07 
error file and is configurable by the user. 

An important related point is that GSAS is designed such that only the main PGE routine can 
terminate processing. Subroutines are not allowed to terminate processing, but should indicate 
a fatal error by passing the appropriate error severity code back to their calling processes. The 
calling process can then exit with the correct exit status result code. 

The ANC07 error file is in standard GSAS “keyword=value” format. This format is text-based 
and consists of a line containing a keyword/value pair delimited by an equal sign (=). The key- 
word is not case sensitive. Spaces are allowed, but not required. Comment lines must be pre- 
pended by a “#” character. As with other ANC07 files, the sections for error and status must 
be delimited by section identifiers. Identifiers for each section are listed below. 

BEG_OF_STATUS= 

...Status section contents... 

END_0 F_S TATU S = 

BEG_OF_ERROR= 

. . .Error section contents. . . 

END OF ERROR 
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The format of the error/status content is defined in Figure 7-1. The keyword can have the 

KEYWORD=nnnnnnxttttttttttttttttttttttttttttttttttttttttttttttttttxsxf f f f f f 

Figure 7-1 Error Ancillary File Format 

value of “ERROR” or “STATUS” and identifies if the line contains an error or status entry. 
The value is a text string with the specific format defined in Table 7-8. 


Table 7-8 Error String Format 


Character 

Positions 

Description 

n 

1-6 

Error code (must be sequential within a section) 

X 

7,58,60 

Space character (delimiter) 

t 

8-57 

Message 

s 

59 

Error severity (see Table 7-1 0) 

f 

61-66 

Frequency of reporting (message is reported on 1st occurrence, then 
every f’th time) 


There is a specific error number for each error/status value. Within the ANC07 file, these error 
numbers are numerically split into multiple sub-sections. Errors have negative numeric desig- 
nations; status messages have positive designations. 

Each major portion of the GSAS software supported by the specific error file begins at a dif- 
ferent subsection number. Within a subsection, error numbers must be consecutive The use of 
sub-sectioning is optional for a simple error file. The GSAS ANC07 error file has 5 subsec- 
tions. Table 7-9 lists each of the subsections and their starting error/status number. 


Table 7-9 Error Sections 


Starting Numbers 

Description 

-10001/10001 

General error/status. 

-20001/20001 

L1A error/status. 

-30001/30001 

Waveform error/status 

-40001/40001 

Atmosphere error/status 

-50001/50001 

Elevation error/status. 


GLAS error messages are designed to inform a user when the software has encountered a 
problem. GLAS status messages are designed to assist the user in observing the flow of the 
processing. Status messages usually alert the user when the software begins execution of a 
subroutine. A great deal of flexibility was designed into this software in order to allow the 
user to customize the error/status display. 
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The user may modify error and status entries in order to configure the severity of the error and 
frequency of printout. The user is cautioned to seek GLAS change-control board approval 
before modifying the severity of an error. GSAS software will terminate processing upon 
receipt of a fatal severity code. Thus, modifying the severity may enable the software to exe- 
cute in a non-tested mode. 

The severity number controls how the GLAS software reacts when an error occurs. The 4 lev- 
els of severity are described in Table 7-10. GLAS software will terminate on a Fatal error. The 
frequency number controls how often an error message is printed out. The first instance of a 
specific error is always printed. Subsequent instances are printed out at the frequency speci- 
fied. All instances are counted and the number of occurrences printed in an output summary. 


Table 7-10 

Error Severity Codes 

Severity 

Description 

0 

No error 

1 

Information/status 

2 

Warning 

3 

Fatal 


7.4 ANC06 Metadata/Log File 

GSAS PGEs create ANC06 output files which contain processing information, error mes- 
sages, and status messages. These files are in a modified version of the GSAS keyword=value 
format. The format of an ANC06 entry is: 

[time] [keyword] = [value] 

The first field [time] is the time in UTC seconds. The time is that of the data being processed 
when the entry was written (if no data have been processed, the time may be 0 or an invalid 
value). The time is a GSAS-standard time representation (UTC seconds). The second field 
[keyword] is a keyword describing the type of information presented. The third field [value] is 
a formatted text message describing the event. Comments are allowed in order to group mes- 
sages logically. Comment lines are pre-pended by the pound (#) sign. 

The value field contains the actual message and its format varies dependent on the type of 
message displayed. Error/Status values, for example, have several subfields. The first field is 
the numeric error/status code. The second field is the error severity (see Section 7 for details). 
The third field is the name of the routine which reported the error. The fourth field is the stan- 
dard error text with optional detailed text. The format of the subfields within the value field is 
shown below: 

error_num, severity, calling_routine , std_message opt_text 
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7.5 Product Internal Data Storage, Conversion and I/O 

The GSAS I/O and unit conversion process is sufficiently complex and important to describe 
in detail.The design of this process is what allows GSAS to meet the reprocessing require- 
ments. 

First, some definitions: (1) algorithm data (in units for algorithm use) are that data which are 
in a form most favorable for display and calculation; (2) product data (in units for I/O) are 
data which are in a form most favorable for machine independence and storage efficiency. It is 
important to understand the process by which algorithm data gets transformed into product 
data (and product data gets transformed back into algorithm data). 

7.5.1 Product Modules 

There are several different types of modules involved in the product conversion process. 
These modules were briefly described in the prod_lib section but will be detailed here. Table 
7-11 (where xx = a GLA product number [01-15]) defines each component. All modules are 
designed with software reuse as a primary goal. 


Table 7-11 

Product Module Functionality 

Module 

Functionality 

kindsjmod 

defines basic data types (4-byte integer, 8-byte real, etc.) 

types_mod 

defines any global data structures 

GLAxx_prod_mod 

defines product-specific (where xx=product number) 
record format and associated global product data struc- 
ture. Each module also includes one subroutine to initialize 
the product data and another to print the data in a human- 
readable form. 

GLAxxjmod 

contains routines to read (ReadGLAxx) and write 
(WriteGLAxx) the product data structure in binary format. 

GLAxx_alg_mod 

defines product-specific global algorithm data structure. 
Each module also includes one subroutine to initialize the 
algorithm data and another to print the data in a human- 
readable form 

GLAxx_scal_mod 

defines product-specific global scaling data structure. Also 
includes subroutines to initialize the scaling data, convert 
from product to algorithm format (GLAxx_P2A), convert 
from algorithm to product format (GLAxx_A2P), and print 
the scaling data in a human-readable form. 

common_flag_mod 

contains routines for packing/unpacking common flags. 

G L Axx_f 1 agjmod 

contains routines for packing/unpacking product-specific 
flags. 
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7.5.2 Internal Product Data Storage 

Data for each product are stored internally in two different formats. For each product, there is 
one global data structure containing product data. These data are in the exact same format as 
the integer-binary data written to and read from GLAS product files. There is also a global 
data structure for each product containing algorithm-format (mostly double precision) data for 
use in scientific calculations. The product modules and the GSAS Managers use these public 
data structures. However, data are passed from the Managers to the science algorithms via the 
argument list. 

7.5.3 Product Input/Output 

GLAxx product files are defined as integer-binary fixed-length files. These product files will 
contain text header records (as described later) followed by binary data records. 

The GLAxx_prod_mod defines a specific data structure which exactly matches the format of 
each data record of the appropriate product file. This data structure is used in an unformatted 
direct-IO statement to read/write a data record from/to disk. 

When multiple products are read simultaneously, a data record from a lower-numbered prod- 
uct is read before the data from a higher-numbered product. This is important to the concept of 
“Pass-thru” (explained in Section 7.5.5). 

7.5.4 Product-to-Algorithm Conversion (P2A) 

When a data record is read from disk into memory, the data are stored in the product data 
structure. In order to be useful in scientific calculations, the data must be converted from 
product format into algorithm format. The process is called “Product-to-Algorithm Conver- 
sion”. 

When a record of data is read, the values are stored in a product data structure. The appropri- 
ate algorithm data structure is initialized to either zeros or invalid values, as specified by the 
product documentation. 

Each product variable is checked for an invalid value. If the data is determined to be invalid, 
no conversion is performed. As a result of initializing the algorithm structure appropriately, if 
the product variable is invalid, the algorithm value, by default, contains an invalid value. 

If the values are determined valid, the data will be converted from product to algorithm format 
by one or more of the following processes. 

• converting to unsigned (if necessary) 

• scaling by a scale factor: 

Algorithm _Value = Product _Value* Scale_Factor 

• unpacking bits into individual flags. 

For the most part, scaling is performed by multiplying the integer product value by a floating 
point scale factor and storing the result in a double-precision algorithm variable within the 
global algorithm data structure. The exceptions to this rule are flags, which are unpacked with 
specific subroutines and a few variables which are used as integers by the science algorithms. 
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7.5.5 Pass-Thru 

After a product is read and converted to algorithm format, common data must be passed from 
lower-numbered product/algorithm data structures to higher-numbered product/algorithm data 
structures. This pass-thru process enables re-processing to be treated the same as normal pro- 
cessing. It is important that both product and algorithm data is passed. The subsystem manag- 
ers (discussed below) are designed to take full advantage of the pass-thru process. 

7.5.6 Managers 

The subsystem managers ‘use’ the global algorithm data structures. If an intermediate conver- 
sion is necessary, the managers create local variables. The managers pass the appropriate vari- 
ables to the science algorithms via the argument list. (LI A is an exception to this since the 
L1A routines basically use the entire data structures.) Specific algorithms are executed based 
on the state of control flags received from the PGE in order to allow for re-processing. 

A key concept is that the manager uses the variable in the highest-numbered product for 
which it is responsible. For example, if the same variable is on GLA05 and GLA06, the eleva- 
tions manager always uses the variable from the GLA06 algorithm structure, no matter if 
GLA06 is read for input or not. The pass-thru process ensures that the value is always there. 

After a science algorithm returns execution to the manager, the manager performs its own 
pass-thru function. It copies any local variables back to the algorithm data structure and then 
passes any modified algorithm variables to the higher-numbered product/algorithm data struc- 
tures. This is essentially a repeat of the pass-thru process described in 7.5.5, except the candi- 
date variables are limited to those modified by each respective science algorithm. 

7.5.7 Algorithm to Product Conversion (A2P) 

After the manager has finished executing science algorithms, each algorithm structure must be 
converted back to product data. This is essentially a reverse of the P2A process. 

First, the product structure is initialized. Then, each algorithm variable is checked for an 
invalid value. If the variable is determined valid, the data will be converted from algorithm to 
product format by one or more of the following processes. 

• unsealing by a scale factor: 

Product_Value = nint(Algorithm_Value/Scale_Factor) 

• unpacking bits into individual flags. 

For the most part, scaling is performed by taking the nearest integer of the double precision 
algorithm value divided by a floating point scale factor. The result is stored back into an inte- 
ger product variable within the global product data structure. The exceptions to this rule are 
flags, which are packed with specific subroutines and a few variables which are used as inte- 
gers by the science algorithms. 

7.6 Product Headers 

GSAS Products begin with ASCII header records containing information regarding the pro- 
cessing which created the Product and the data contained within. These header records are 
exactly the same size as a Product data record and contain ASCII information in a slightly 
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modified KEYWORD= VALUE format. In order to conserve space on the product, the header 
entries are not delimited by the record length, but by a semi-colon (;) and linefeed (ASCII 10). 

By design, the first two header entries are the record length and number of header records. 
This allows product readers to verify the record length and jump directly to the first data 
record, if necessary. Most of the remaining information within the headers is directly applica- 
ble to the generation of metadata files for EOS ingest. 

Although the majority of entries in the Product headers are common to all products, GSAS 
Products may contain special and specific header entries. This is handled by product-specific 
header modules (GLAxxhdrmod). The common elements of the Product Headers and asso- 
ciated subroutines are contained within a common header module (common_hdr_mod). Most 
of the header software is contained within the GSAS product library. The exception is the 
comhdrupdate routine, which is contained within the exec_lib since it needs to interface 
more directly with the PGEs. 

When a product file is opened for output, GSAS initializes the product’s header information 
and determines how many records will be needed to contain the header data. Many of the 
header entry values are already known at this time and can be filled in immediately. A fixed 
number of bytes is reserved for those entries whose values must be filled at a later time. GSAS 
writes the initial header records to the product and sets the file pointer to the first data record. 
At the end of a granule, any of those unfilled header records are set to a value and the header 
records are re-written at the top of the Product. Care is taken to make sure that the header 
records have not grown large enough to overwrite any Product data. 

7.7 Summary 

Again, it is important for developers to realize the capability built into the GSAS libraries. 
Use of the PGE model presented in the next section can lead to significant reductions in devel- 
opment time and much greater consistency throughout the GLAS software. 

GLASReader was written partially as an example for the capability gained through using the 
libraries. With only about 1300 lines of heavily commented code (and most other lines sub- 
routine calls), GLAS_Reader uses the product library routines to read and print nearly any 
GLAS file currently in use. The services it uses include: 

• Full control file parsing. 

• Time-selective processing. 

• Multi-granule processing. 

• Full error reporting. 

• Full I/O support. 

• Full ANC06 logging. 

Additionally, a fairly significant portion of the 1300 lines includes a rudimentary user inter- 
face which allows a user to interact with GLAS_Reader without requiring a control file. This 
shows that the use of the libraries does not necessarily restrict the developer to follow the con- 
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ventional GSAS model. The model provides developer with the flexibility to handle special 
requirements within the basic development GSAS model. 
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GLAS_LOproc 


8.1 Overview 

GLAS Level 0 APID files will normally be distributed as a PDS (Production Data Set) in 
approximately 6 hour segments or as an EDS (Expedited Data Set) which will be distributed 
as a Pass Data Dump. There will be several files, each containing a specific APID record for 
the segment. These segments will be sets of real-time and playback data received from the 
polar ground stations. The software that will pre-process GLAS LO data is the GLAS Level-0 
Processor (GLASLOproc). 

8.2 Function 

GLAS LOproc is a utility PGE that will time synchronize GLAOO APIDs in a manner such 
that records within different GLAS products may be easily correlated. To do this 
GLAS LOproc creates a unique number (rec_ndx) for each packet of data collected by the 
GLAS instrument. This index will be assigned to the matching records within each Level 0 
APID and will account for the 0.25 second waveform Altimeter Digitizer packets 

GLAS_L0proc will read each input APID and ancillary file listed in the control file and pro- 
duce a single index file (ANC29) and a single GPS time correction file (ANC32). The 
ANC29 file will contain an index to each record in the set of files in the PDS/EDS. The pro- 
gram will group the data in one-second intervals. The ANC32 file will be used during L1A 
processing to assist in precise laser shot time -tagging. 

GLAS LOproc will also perform limited error checking on the APIDs it reads. It will signal an 
error if more than the maximum allowed APID records fall within a second and write a warn- 
ing message to ANC06. Several fields within the APID primary header will be checked 
against reference values. These errors will be flagged and recorded. Duplicate APID records 
are checked, flagged and recorded, as well. 

The core GLAS PGEs are used as a model for GLAS LOproc. A major difference in the 
GLAS_L0proc implementation is that it reads the APIDs one file at a time, rather than syn- 
chronously reading all the APIDs record by record. Despite this difference, a great deal of the 
PGE model was used to create GLAS_L0proc, which will ease software maintenance chores. 

Developer experience is that working with LO spacecraft data can entail a great deal of debug- 
ging with regards to both software and the actual data. With this in mind, a significant amount 
of debug code is embedded within GLAS_L0proc. This code can be turned on with compiler 
flags but will generate an extensive amount of output. This output is very useful for debugging 
purposes but can drastically slow execution time. The recommended method of running with 
debugging turned on is to redirect stdout to a file which can be examined after the run. 

GLAS LOproc records statistics such as the number of missing records, number of received 
records, number of bad records, etc. The software checks for too many occurrences of an 
APID per second. Duplicate data is flagged as an error (warning not fatal) and the message 
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written to ANC06. Quality issues are tracked and reports made of any problems/potential 
problems. 

8.3 Approach 

• GLAS_LOproc uses many of the standard routines from the model GSAS PGE with 
only minor changes. 

• GLAS_LOproc does not perform partial/selective processing or reprocessing. There 
are no execution flags defined within GLAS_LOproc. Start and stop time are required 
on control file INPUTFILE and OUTPUT_FILE specifications for consistency, but 
are not used. 

• GLAS_LOproc uses the operating system-based qsort for sorting tasks. Glue code 
written in C is used in conjunction with qsort. 

• Several constants are needed by GLASLOproc processing. Constants include such 
things at mission elapsed time (MET) offsets, APID identification code, APID record 
lengths, and sort order keys. These constants are included within the GLAOO product 
module in order to facilitate code reuse and ease configuration management. 

• The manager functionality is within the main GLAS LOproc routine. 

• ReadData is not used since data is read file-by-file, rather than record-by-record. 

8.4 Input and Output Files 

Table 8-1 lists the required inputs to GLAS_LOproc. Table 8-2 lists the outputs created by 
GLAS_LOproc. Files which are specific to GLAS LOproc are documented in this section. See 
the appropriate section of this document or the GLAS Science Data Management Plan for 
details regarding the those files not specific to GLAS LOproc 
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Table 8-1 GLAS_LOproc Inputs 


File Spec 

Type 

Source 

Short Description 

gla00*_??.dat 

Level-0 APID 

EDOS 

GLAS Level-0 APID files (one 
file per each APID type). 

anc47*_??.dat 

Level-0 

EDOS 

GLAS Level-0 APID PDS files 
(one file per each APID type) 

anc07*_00.dat 

Static Ancillary 

Science Team 

GLAS error file. 

anc07*_0 1.dat 

Static Ancillary 

Science Team 

GLAS global constants file. 

anc33*.dat 

Dynamic Ancillary 

ISIPS Operations 

Counter-to-UTC conversion file. 

Control File 

Control 

ISIPS Operations 

Control file. 


Table 8-2 GLAS_LOproc Outputs 


File Spec 

Type 

Destination 

Short 

Description 

anc29*.dat 

Dynamic Ancillary 

GLAS_L1A 

Index file corre- 
lating APID 
times. 

anc32*.dat 

Dynamic Ancillary 

GLAS_L1A 

GPS time correc- 
tion file used for 
precision timing 
of GLAS data. 

anc06*.dat 

Dynamic Ancillary 

ISIPS Operations 

Standard meta- 
data/processing 
log file. 
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8.4.1 GLAOO APID Files 

The GLAOO APIDs are Level-0 multi-rate spacecraft data files provided to the GLAS data 
processing facility by EDOS. There is a separate file for each specific APID type received 
from the spacecraft. These files are fully documented by the GLAS Instrument Team and 
within the GLAS L1A ATBD. These APIDs are listed in Table 8-3. 


Table 8-3 Supported APIDs 


APID 

Description 

12 

Altimeter Digitizer Large Sci Pkt 

13 

Altimeter Digitizer Small Sci Pkt 

14 

Altimeter Digitizer Eng Pkt 

15 

Photon Counter Sci Pkt 

16 

Photon Counter Eng Pkt 

17 

Cloud Digitizer Sci Pkt 

18 

Cloud Digitizer Eng Pkt 

19 

Ancillary Science Pkt 

20 

CT HW telemetry #1 Data Pkt 

21 

CT HW Telemetry #2 Data Pkt 

22 

CT HW Telemetry #3 Data Pkt 

23 

CT HW telemetry #4 Data Pkt 

24 

Small Software #1 Tim 

25 

Large Software Telemetry #1 Packet 

26 

LPA Data Pkt 

27 

Memory Dwell Packets 1 

28 

Memory Dwell Packets 2 

31 

DSP Code Memory Dump 

32 

DSP Data Memory Dump 

33 

C & T Dwell Packet 

34 

Event Message Packet 

35 

Memory Dump Packet 

36 

Table Dump Packet 

38 

Boresite Calibration Packet 

48 

GLAS Data Types Packet 

49 

Command History Packet 
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Table 8-3 Supported APIDs (Continued) 


APID 

Description 

50 

CT HW telemetry #5 Data Pkt 

55 

Large Software Telemetry #2 Packet 

126 

LPA Test Packet 

1984 

GLAS PRAP Packet 


8.4.2 ANC47 PDS Files 

The ANC47 PDS files are Level-0 construction record data files provided to the GLAS data 
processing facility by EDOS. There is a separate file for each specific APID type received 
from the spacecraft. These files indicate the quality of the corresponding GLAOO data. 

8.4.3 ANC33 MET Counter to UTC Conversion File 

The ANC33 file is used to convert mission-elapsed time (MET), which is provided in the 
APIDs, to GLAS-standard UTC time. Since the MET can be re-set by a roll-over or a space- 
craft upset it is important that this file be maintained and provided to the GLAS processing 
facility in a timely manner. The file is delivered to ISIPS from the ISF as described in the ISF/ 
ISIPS Interface Control Document. 

ANC33 file is a ANSI text file. Each line contains data for a single entry in the file (data 
should not be hard wrapped). Comment lines are allowed and prepended by a # character. 
Each line contains the following information: 

d_shdr_count <sp> d_shdr_count_prap <sp> d_utc <sp> 
d_glas_osc_rate <sp> d_sc_osc_rate <sp> d_tdelay_digtzr <sp> 
d_rdelay_digtzr <sp> d_plTbias <sp> d_plRbias <sp>d_siru_e 
<sp> d_siru_e2 <sp> i_trkr_sub j ectl <sp> i_trkr_subj ect2 
<sp> i_trkr_sub j ect2 <sp> instrument_state 
<sp>implement_time 

Each field is defined in Table 8-4. 


Table 8-4 ANC33 Field Descriptions 


Field 

Description 

d_shdr_count 

double precision: the counter value in the secondary header on MOST 
APIDS 

d_shdr_count_prap 

doube precision: the counter value in the secondary header of PRAP 

d_utc 

double precison: the J2000 UTC time in seconds to which the counter val- 
ues are converted 

d_glas_osc_rate 

double precision: the GLAS oscillator rate 

d_sc_osc_rate 

double precision: the Spacecraft oscillator rate 

d_tdelay_digtzr 

double precision: time delay for digitizer in seconds 
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Table 8-4 ANC33 Field Descriptions (Continued) 


Field 

Description 

d_rdelay_digtzr 

double precision: internal range delay for digitizer in m 

d_plTbias 

double precision: post launch time bias in seconds 

d_plRbias 

double precision: post launch range bias in m 

d_siru_e 

double precision: initial slope for SIRU VTCW correction 

d_siru_e2 

double precision: secondary slope for SIRU VTCW correction 

i_trkr_subject(1 ) 

integer: the subject indicator for LRS tracker 0 

i_trkr_subject(2) 

integer: the subject indicator for LRS tracker 1 

i_trkr_subject(3) 

integer: the subject indicator for LRS tracker 2 

instrument_state 

integer bitfield: Initial valid instrument state for the period (see LI A Stan- 
dard Data Product for bit interpretation) 

d_implement_time 

double precision: the J2000 UTC time in seconds where the data are first 
valid 


Note that the Implement_time is the UTC time at which this conversion was valid. 
GLASLOproc uses the designated start time of the first APID specified in the control file to 
find the correct position within the ANC33 file based on the Implement time field. 

8.4.4 Control File 

The control file format and common elements are documented in Section 5 of this document. 
Elements specific to GLAS_LOproc are described here. 

The control file section delimiter for GLAS LOproc is: 

=GLAS_L0P 

Since GLAS_LOproc has no requirement for execution scenarios, there are no unique key- 
words for the GLAS_LOproc control file. GLAS LOproc will perform all functions based on 
the presence of input and output files within the control file. 

8.4.5 ANC29 Index File 

The ANC29 index file provides GLAS_L1A with a method of time-correlating the GLAS 
APID files. It contains an index record for every record in the input APID files. ANC29 is a 
binary, fixed-length record file. Its format and fields are described in Table 8-5. 

8.4.6 ANC32 GPS File 

The ANC32 GPS file provides GLAS_L1 A with a method of computing precise timing calcu- 
lations based on the last update of the onboard GPS. It contains records which identify each 
time the GPS clock is updated within the APID packets. ANC33 is a binary, fixed-length 
record file. Its format is described in Table 8-6. 
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Table 8-5 ANC29 Format/Description 


Variable 

Type 

Bytes 

Description 

utctime 

double precision 

8 

J2000 UTC time in seconds. Computed from the 
MET counter in each APID’s secondary header. 

rec_ndx 

long integer 

4 

Mission-unique index number assigned to the set of 
APIDs defined by a one second duration and group- 
ing rules. This number will be assigned to corre- 
sponding data records in every GLAS data product. 
The value is nominally (utctime - launchtime) * 5, in 
seconds. 

shot_ctr 

long integer 

4 

The appropriate shot counter from each APID. 

rec_num 

long integer 

4 

The physical record number of the corresponding 
data within the APID file. 

apid 

long integer 

4 

The APID number (assigned by the spacecraft 
team) of the APID. 

DQFlag 

long integer 

4 

Data quality flag. 

sort_order 

short integer 

2 

Sort order (for internal use). 

spare 

short integer 

24 

Spare bytes to align data structure to 8-byte bound- 
ary. 


Table 8-6 ANC32 Format/Description 


Variable 

Type 

Bytes 

Description 

rec_ndx 

long integer 

4 

Mission-unique index number assigned to 
the set of APIDs defined by a one second 
duration and grouping rules. This number 
will be assigned to corresponding data 
records in every GLAS data product. The 
value is nominally (utctime - launchtime) * 
5, in seconds. 

i_ScPosPktShot 

short integer 

2 

Shot counter within APID 19 position 
packet, starting at byte location 11 82. 

i_useflag 

short integer 

2 

Flag indicating if the data are valid (0=valid, 
other=not valid). 

utctime 

double precision 

8 

UTC time in J2000 seconds where GPS 
update occurred. This value corresponds 
exactly to a UTC time in the ANC29 file. 

FTLatch 

double precision 

8 

Frequency board latch counter within 
APID19, starting at byte location 1195. 

ScPosPktGMET 

double precision 

8 

MET counts within APID 19 position packet, 
starting at byte location 1184. 
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Table 8-6 ANC32 Format/Description (Continued) 


Variable 

Type 

Bytes 

Description 

d_VTCW 

double precision 

8 

BCTCW latch value within APID19 starting 
at byte location 1142. 

d_VTCWp 

double precision 

8 

VTCW value at time of 0.1 Hz pulse within 
APID19 starting at byte location 1182. 

GPSTime 

double precision 

8 

GPS receiver time in counts within APID19 
starting at byte location 1172. 

GPSppsGMET 

double precision 

8 

MET for GPS 0.1 hz counter within APID19 
starting at byte location 1201. 


8.5 Design 

Figure 8-1 shows the top-level structure chart of GLASLOproc. The basic processing algo- 
rithm is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl lnit) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (Print Cntl) 

• Read static ancillary files (ReadAnc) 

• Write version info (Write_LibVer, Write_AncVer) 

• Until all APID files are read... 

Read APIDs and fill index and gps arrays (readglop) 

• Sort the index array (sort glaOO index) 

• Sort the GPS array (sort gps) 

• Convert the MET time into UTC time (utc_time_conversion) 

• Group the APID records and assign rec ndx (IndexGrouping) 

• Check the index array for duplicates 

• Write the index arrays to file 

• Assign rec ndx to GPS array entries 

• Validate data within GPS array and set useflag appropriately 

• Write GPS array to file 

• Close all files and generate summaries (Main Wrap) 
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Figure 8-1 GLAS_LOproc Structure Chart 
8.5.1 PGE Core Routines 

Except where noted, the following PGE core routines are used exactly as defined in the Core 
PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• WriteLibVer 

• ReadANC 

• WriteAncVer 

• MainWrap 

Exceptions to normal core routine conventions include: 

• eCntl_Init does not define or set execution flags. 

• GetControl does not parse any execution flags. 

• Start and stop times are required on the INPUT/OUTPUT FILE assignments, but are 
not used by GLAS_LOproc to delimit processing. However, the start time of the first 
APID specified is used as a reference time when finding the correct coefficient for 
MET-to-UTC conversion. It is critical that this time is specified correctly. 
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8.5.2 ReadGLOP 

ReadGLOP is a subroutine within the local glop mod module. The glop_mod itself contains 
several important constants. Since GLASLOproc creates its index and GPS arrays in mem- 
ory, a maximum length for each array is defined in this module. The arrays themselves are 
defined and allocated in this module, as well. 

ReadGLOP is called by the main GLAS LOproc routine once for each APID which is to be 
processed. ReadGLOP uses the APID number to read each record of the APID into the appro- 
priate data structure. 

ReadGLOP uses standard Fortran direct-to-structure reads to read most APIDs. However, sev- 
eral APIDs are not aligned on 4-byte boundaries. For these, ReadGLOP calls specialized read 
subroutines which exist within the GLAOOmod module of the product library. 

If the APID read is an Ancillary Science Packet (APID 19), GPS time is compared with the 
previous GPS time. If a change has occurred, a GPS array element is filled with the appropri- 
ate data. 

The primary header of each APID record is converted and checked for error conditions. Error 
checking includes the following: 

• Primary header version = 0 

• Primary header APID number = expected APID 

• Primary header APID size = expected APID size - (header size - 1) 

(actual value of the offset is 7) 

• Primary header secondary header flag /= 0 

• Primary header sequence count delta = 1 

Duplicate records are checked by comparing the sequence counter and utctime against previ- 
ous values. 

Fields within the index structure are filled and a “sort rank” is assigned based on the APID 
type. This “sort rank” is temporarily assigned to the spare 4 bytes at the end of the data struc- 
ture. The shot counter is converted from a signed to unsigned value before assignment. 

Since the MET-to-UTC conversion has not yet been performed, the MET counter is assigned 
to the utctime. However, an APID-specific offset is added to the MET counter for alignment 
purposes in order to account for processing delays aboard the spacecraft. These values were 
provided by the instrument developers and are defined in the GLA00_mod module within the 
product library. 

8.5.3 sort_glaOO_index 

Sort glaOO index is a C routine local to GLAS_LOproc. It provides a comparison function for 
the system qsort routine and calls qsort with the index array, qsort returns an index array 
sorted by utctime (primary) and sort rank (secondary). Sorting the index provides a list of 
interspersed APID records in time/rank order. Sorting is necessary so that the index grouping 
module can correctly assign a rec_ndx to the correct group of corresponding APID records. 
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An important programmer note is that a C header file (glaOOindex.h) is required for 
sort_glaOO_index. If a programmer changes the Index file data structure, they must change the 
glaOO index.h file in a corresponding manner. 

8.5.4 sort_gps 

Sortgps is a C routine local to GLASLOproc which is nearly identical to sortglaOOindex. 
It sorts the GPS array by utctime using a comparison routine with the system qsort call. (This 
is actually done more for safety than necessity.) 

The same caveat applies here as does with sort glaOO index. A C header file (gpsindex.h) is 
required for sort gps. If a programmer changes the GPS file data structure, they must change 
the gps index.h file in a corresponding manner. 

8.5.5 utc_time_conversion 

UTC_time_conversion is a routine local to GLAS LOproc. It reads reference values from 
ANC33 and uses those values to convert MET counter values within the index array to UTC 
time. 

The routine is passed the start time (taken from the control file entry) of the lowest-numbered 
APID which has been read. It uses this as it’s initial time and searches through the ANC33 file 
for the first implement time greater than or equal to the initial time. 

Once it has found the correct implement time, it loops through the index array and uses the 
associated refMET_Counts, refUTC_seconds, and Interval to convert the MET counter to 
UTC time within the index. While looping, it checks to see if the previously computed UTC 
time is greater than the next implement time. If so, it reads the associated ANC33 values and 
uses those for the next UTC conversions. 

Additionally, while looping through the index file, the routine checks the GPS array for 
matches between the APID 19 index MET counter and GPS MET counter. If a match is found, 
the GPS MET counter is converted to UTC time. 

The UTC time conversion calculation is performed as follows: 

UTC time = refUTC_seconds + (MET counter - refMET_Counts) * Interval 

8.5.6 lndex_Grouping 

Index_grouping is a routine local to GLAS_LOproc. It scans through the index array and 
assigns recndx values based on a data alignment algorithm. 

Sort_glaOO_index has already sorted the index array based on MET counts and sort rank. 
Based on information from the instrument team, certain APIDs are guaranteed to have the 
same MET counter value for a particular second of data. The sort rank takes this into account 
and sorts these APIDs at a higher level than others. Additionally, the sort order also accounts 
for importance, guaranteeing that if an APID record exists for a certain second, it will be in a 
fixed position relative to other APIDs within the one second interval. 

The routine loops through the index array. When it detects one of the higher-ranked APIDs, it 
computes a rec ndx from the UTC time. This rec ndx is assigned to the current APID record 
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and subsequent APID records until another higher-ranked APID is detected. During the period 
of assigning the recndx, several error checks are performed. These are: 

• The number of specific APID types assigned the same rec ndx is checked against a 
reference maximum- APID-per-second reference (which is defined in GLAOOmod.) If 
the maximum of a specific APID is exceeded, the rec_ndx value is recomputed and 
assigned to the current and subsequent APIDs. 

• The shot counter values of specific APIDs (ADLgSci, ADSmSci, ADEng, PCSci, 
PCEng, CDSci, CDEng, AN Sci, LPA) are checked for consistency. If the shot 
counters within the same rec ndx are inconsistent, the rec ndx value is recomputed 
and assigned to the current and subsequent APIDs 
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9.1 Overview 

GLAS_L1A is a core GSAS PGE. It uses the LI A subsystem to create GLAS Level 1A data 
from the Level 0 GLAS instrument data products. GLAS_L1A will use the ANC29 and 
ANC32 files created by GLAS LOproc to time-synchronously read the appropriate GLAOO 
APID files. 

9.2 Function 

The LI A process includes applying calibration equations determined during GLAS system 
testing to convert the measured counts into engineering units. The conversions of the counts to 
engineering units will be one or more of several types: straight polynomial conversion based 
on the measurement counts; multi-variable conversions with dependence on additional mea- 
surements such as temperature; special conversions based on a complex dependence of sev- 
eral measurements, interpretation of data, table look-up, and geophysical based conversions. 
Some data will not require conversion and will be retained in counts. The Stellar Reference 
System (SRS) attitude and position data and the GPS data will be from standard existing sys- 
tems similar to those used on other spacecraft. The conversions and calibration equations for 
the LI A subsystem are defined the LI A ATBD. 

The altimeter data, including the waveforms, are packaged into the GLA01 data product. The 
atmospheric data from the photon counters and the cloud digitizer, as well as supporting data, 
are packaged into the GLA02 data product. Both GLA01 and GLA02 include location data 
obtained from the predicted orbit file. The GLAS instrument engineering and housekeeping 
data are stored in the GLA03 data product. The SRS and GPS data along with the laser point- 
ing monitor data will be packaged into the GLA04 data product. 

9.3 Design Approach 

The following design criteria are specific to GLAS_L1A. 

• GLAS L1 A fully uses the standard routines from the model GSAS PGE. 

• GLAS L1 A can perform partial processing, but not reprocessing. GLAS_L1A does 
perform time-based selective processing. There are, however, dependencies between 
LlA Atm and LlA Alt. Partial-processing will not yield the same results for certain 
parameters as full-processing. 

• The ANC29 file (created by GLAS_LOproc) is used to read GLAOO data from the 
appropriate APID file in the correct order. 

• Due to issues due to aligning multi-rate data across PDS boundaries, the ANC29 and 
ANC32 files are read into core and re-sorted. This is a break from the concept of nor- 
mal record-by-record processing. 
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• LlAMgr is specific to the LI A subsystem. The LI A manager is used to control all 
LI A-specific science algorithm processes and interfaces directly with the LI A subsys- 
tem. 

9.4 Input and Output Files 

Table 9-1 lists the required inputs to GLAS L1A. Table 9-2 lists the outputs created by 
GLAS L1A. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files. 


Table 9-1 GLAS_L1A Inputs 


File Spec 

Type 

Source 

Short Description 

gla00*_??-dat 

Level-0 APID 

EDOS 

Level-0 APID files (one file per 
each APID type). 

anc07*_00.dat 

Static Ancillary 

Science Team 

Error file. 

anc07*_0Ldat 

Static Ancillary 

Science Team 

Global constants file. 

anc07*_05.dat 

Static Ancillary 

Science Team 

L1A constants file. 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion file. 

anc29*.dat 

Dynamic Ancillary 

GLAS_L0proc 

APID index file. 

anc32*.dat 

Dynamic Ancillary 

GLAS_L0proc 

GPS time correlation file. 

anc33*.dat 

Dynamic Ancillary 

Science Team 

UTC time conversion file. 

anc20*.dat 

Dynamic Ancillary 

UTexas 

Predicted orbit file. 

anc45*_0Ldat 

Static Ancillary 

Science Team 

GLA01 metadata input file. 

anc45*_02.dat 

Static Ancillary 

Science Team 

GLA02 metadata input file. 

anc45*_03.dat 

Static Ancillary 

Science Team 

GLA03 metadata input file. 

anc45MM.dat 

Static Ancillary 

Science Team 

GLA04 metadata input file. 

Control File 

Control 

ISIPS Operations 

Control file. 


Version 6.0 


Page 9-2 


March 2013 






GLAS LI A 


The GLAS Science Algorithm Software Detailed Design Document 


Table 9-2 GLAS_L1A Outputs 


File Spec 

Type 

Destination 

Short Description 

gla01*.dat 

LI A Product 

GLAS_L1A 

GLAS LI A Altimetry product file. 
Contains the waveforms and the 
altimeter and timing data 
required to produce higher level 
range and elevation products. 

gla02*.dat 

LI A Product 

GLAS_Atm 

GLAS LI A Atmosphere product 
file. Contains the normalized 
backscatter, photon counter, 
cloud digitizer, timing, and 
location data required to pro- 
duce the higher level atmo- 
sphere data products. 

gla03*.dat 

LI A Product 

Archive 

LI A Engineering product file. 
Contains the GLAS instrument’s 
engineering and housekeeping 
data. 

gla04*_01.dat 

LI A Products 

UTEXAS 

LI A LPA product file. 

gla04*_02.dat 

LI A Products 

UTEXAS 

LI A LRS product file. 

gla04M53.dat 

LI A Products 

UTEXAS 

LI A GYRO product file. 

gla04MD4.dat 

LI A Products 

UTEXAS 

L1A 1ST product file. 

gla04*_05.dat 

LI A Products 

UTEXAS 

L1A BST product file. 

gla04*_06.dat 

LI A Products 

UTEXAS 

LI A SCPA product file. 

qap01*.dat 

LI A Quality 

QA 

LI A Altimetry quality file. 

qap02*.dat 

L1A Quality 

QA 

L1A Atmosphere quality file. 

qap03*.dat 

L1A Quality 

QA 

LI A Engineering quality file. 

qap04*.dat 

L1A Quality 

QA 

L1A SRS/GPS/laser pointing 
quality files. 

anc06*.dat 

Dynamic Ancillary 

ISIPS Operations 

Standard metadata/processing 
log file. 


9.5 GLAS_L1A PGE 

Figure 9-1 shows the top-level structure chart of GLAS_L1A. The basic processing algorithm 
is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 
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• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (Print_Cntl) 

• Read ancillary files (ReadAnc) 

• Write version info (Write_LibVer, Write_AncVer) 

• Until all data are processed... 

- Execute the LI A Manager 

• Close all files and generate summaries (Main Wrap) 



Figure 9-1 GLAS_L1A Structure Chart 


9.5.1 PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• WriteLibVer 

• ReadANC 

• WriteAncVer 

• ReadData 

• MainWrap 
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9.6 L1A Manager (L1A_Mgr) 

The LI A Manager controls execution of the LI A subsystem, passes variables from the 
GLAOO APIDs to the LI A products, and handles granule start/stop. The manager controls 
execution of the science algorithms based on flags received from the control fde via 
GLAS_L1A. Figure 9-2 shows the L1A Manager Structure Chart. Figure 9-3 shows a flow 



Figure 9-2 L1A_Mgr Structure Chart 


chart of the LI A Manager. 

LI A_Mgr is passed arrays of output file control structures and execution flags. It accesses 
product and algorithm data directly from the requisite public data structures. Execution flags 
are defined in eCntl_mod; file control structures defined in the fCntl_mod component of the 
exec lib, and product/algorithm data within the GLAOO, GLA01, GLA02, GLA03, and 
GLA04 components of the product_lib. 

The first thing the manager does is check for an end-of-granule condition within each defined 
output file by comparing the nominal time of data (set by ReadDatamod) with the appropri- 
ate stop time within the specific file data structure. If an end-of-granule condition is detected, 
final QA routines are called and the product and QA files are closed. If another granule of the 
same type has been specified in the control file, the manager opens the appropriate product 
and QA files and loops to verify the stop time of the new granule is greater than the nominal 
time of data. 

After checking the granule times, processing begins. The manager calls calc_shot_time, 
which computes precise 40 per second timing information. It then calls C_CalcSpLoc which 
computes 40 spot locations based on the 40 per second timing information and the location of 
satellite position interpolated from the predicted orbit file (ANC20). 

Next, the manager executes several science algorithms based on its execution flags and data 
availability. L_Eng, L Alt, L_Atm, and L_Att are called. Each returns a flag indicating if the 
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LlAMgr 

7 / 21/00 



Figure 9-3 L1A Manager Flow Chart 

appropriate data product should be written. Values which are passed directly from one product 
to another are set appropriately. 

QA routines are called to process QA information and the WriteLlA routine is called with the 
appropriate flags to write data to the product files. Before writing a record, WriteLlA verifies 
that the appropriate output file exists and that the nominal time of data is greater than the start 
time specified in file control structure. If the nominal time is less than the start time, the data 
record is not written. An appropriate error message is written to ANC06 if a record is skipped. 

9.7 PGE/Manager Implementation Details 

This section discusses specific aspects of the PGE/Manager implementation which should be 
addressed in more detail. 

9.7.1 ANC29/ANC32/GLA00 Input 

ANC29 data are handled differently than most core PGE I/O. Due to potential PDS boundary 
problems (for example, the waveform data for a particular second may be on a different PDS 
than the corresponding ancillary science data), all input ANC29 granules are read into mem- 
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ory by the ReadAnc core PGE routine. This array is dynamically allocated based on the num- 
ber of records indicated in each ANC29 file header. The internal file number from which the 
ANC29 data are read is stored into a spare byte in the array so that when GLAOO data are read, 
the corresponding GLAOO file is used. After the ANC29 granules are read into memory, the 
data are sorted to guarantee the correct time order. ANC32 data are loaded into memory simi- 
larly. 

ReadData actually “reads” the ANC29 and ANC32 data on a second-by-second basis from 
memory. As the specialized ANC29/32 I/O was a fairly late design decision, this implementa- 
tion minimized changes to the ReadData logic. ReadData uses the ANC29 data to read the 
correct records from the various GLAOO APID files. It reads 1 -second groups of APID records 
using the physical record number, APID type, and internal file number to determine the cor- 
rect position within the GLAOO files. 

ReadData determines the content of a 1 -second group by examining ANC29 rec_ndx values, 
“rec ndx” is described fully in the GLASLOproc section, but suffice to say, it is an integer 
corresponding to 0.1 second utctimes. Lor the most part, rec_ndx values for APIDs of a partic- 
ular second are the same exact value. However, in the case of APIDs which straddle PGEs, the 
values may not be exactly the same. To handle this case, ReadData will consider that rec_ndx 
values which correspond within 0.9 seconds are part of the same second. This value is a con- 
stant defined in GLA00_mod.f90 as “rec_ndx_slop”. 

9.7.2 Missing APIDs 

Different GLAS APID packets originate from different subsystems of the GLAS instrument. 
Depending upon the instrument state, APIDs may or may not be present in the data stream. In 
addition, data drop-outs present the possibility of missing data. 

The LI A Manager sets an array of flags (APIDAvFlg) to indicate present or missing data. A 
signal flag is set for each 1 -second APID record. The complication arises when checking the 
1/4 second APID waveform records AD LgSci, AD_SmSci). In order to figure out which of 
the four records are missing, the manager examines shot counters. By definition, the shot 
counter in the Ancillary Science (AN Sci) APID will match the first shot counter in the first 
corresponding waveform record. The manager uses this knowledge to set positional flags that 
indicate which of the 1/4 waveform APIDs are missing. 

If at least one of the waveform records or the ANSci record is available, LI A_Mgr calls 
L Alt and a GLA01 record is written. If the Photon Counter Science (PC Sci), Cloud Digi- 
tizer Science (CD_Sci), or AN Sci records are available, LI A Mgr calls L_Atm and a 
GLA02 record is written. 

The GLA01 product file is a little different than the other GLAS products in that it contains 
different record types. It has the following record types: main, large waveform, and small 
waveform. The main record type occurs once per second. The large waveform type occurs 
five per second. The small waveform type occurs twice per second. A record identifier 
(i_gla01_rectype) within each record identifies what type that record is. If at least one of the 
waveform records or the AN_Sci record is available, the Main record type exists in GLA01 
for a particular second. If at least one of the waveform records is available, the waveform type 
(small or large) records exist in GLA01 for that second. 
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9.8 L1A_Subsystem 

Figure 9-4 illustrates the processes that comprise the LI A subsystem. 



Figure 9-4 Level 1A Computations 

9.8.1 Subsystem Design Decisions and Assumptions 

The following design decisions were made: 

• We will perform the precision shot time calculation in its own module since this infor- 
mation is required for geolocation. 

• Any Altimetry data required for L_Atm will be computed in LlA_Mgr. 

The following assumptions were made: 

• LI A will not be executed if LEng is not executed. 

9.8.2 DFDs and their Descriptions 

9.8.2. 1 Level 1 A Altimeter Processing 

The purpose of the Level 1A Altimeter Processing (process 2.1) is to generate the data to be 
stored on the Level 1 A Altimeter Data product (GLA01). This process performs engineering 
unit conversion on the raw Level 0 altimetry data (Alt ln) to obtain the Level 1 A altimetry 
data in engineering units. Any engineering/ housekeeping data that are required to be on the 
GLA01 data product are collected here and placed in the output structure. Quality assessment 
computations are performed, collected and placed in an output QA structure. 
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9.8.2.2 LI A Atmosphere Processing 

The purpose of the LI A Atmosphere Processing (process 2.2) is to generate the data to be 
stored on the Level 1 A Atmosphere Data product (GLA02). This process performs engineer- 
ing unit conversion on the raw Level 0 atmosphere data (Atm_In) to obtain the Level 1A 
atmosphere data in engineering units. Any engineering/ housekeeping data that are required to 
be on the GLA02 data product are collected here and placed in the output structure. Quality 
assessment computations are performed, collected and placed in an output QA structure. 

9.8.2.3 Engineering Data Processing 

The purpose of the Engineering Data Processing (process 2.3) is to generate the data for the 
Level 1 A Engineering Data product (GLA03). This process performs engineering unit conver- 
sion on the raw Level 0 engineering/housekeeping data (Eng ln) to obtain the Level 1 A engi- 
neering data in engineering units. Any Level 0 data that are not stored on either GLA01, 
GLA02, or GLA04 are collected here and placed in the output structure. Quality assessment 
computations are performed, collected and placed in an output QA structure. 

Additionally, specific parameters of the Eng Out structure are passed to the Altimetry and 
Atmosphere processors. 

9.8.2.4 Collect Instrument and S/C Position and Attitude 

The purpose of process 2.4 is to collect the GPS data, instrument and S/C position and attitude 
data and to generate the LI A Position and Attitude data product (GLA04). The APIDs used to 
generate GLA04 include APID19, APID26, and APID1984. The GLA04 product is required 
for input to the precision orbit and attitude determination algorithms. This process checks the 
Level 0 packets for errors, configures the data for output and collects QA data. 

Due to internal spacecraft/instrument timing issues all data corresponding to one second of 
GLA04 data may not be within one second of APID1984. To align the LRS and 1ST data to 
corresponding APID19 shot times, a 6 second double-buffering algorithm is used to match the 
LRS and 1ST data with corresponding APID19 shots. To complicate matters, the LRS and 1ST 
data occur at a rate of 10/second, whereas the APID19 shots occur at a rate of 40/second. The 
algorithm finds the APID19 shots closest to the LRS/IST data and merges the APID19 and 
APID1984 data into a single one second GLA04 record. 

9.8.2.5 Calculate Shot Time 

The Calculate Shot Time process (process 2.5) will generate the precise time of each laser 
shot. The actual methodology of the time calculation depends upon the presence of the Ancil- 
lary Science (AN_Sci) APID. If AN_Sci is not present, 40-per-second time is generated lin- 
early using a 0.025 increment. If AN_Sci is available, the time will be calculated from the 
laser fire time, GPS time, and the GPS latch time. Offsets and calibration factors will be 
applied as necessary. The process is fully described in the LI A ATBD. 

9. 8.2. 6 Get Predicted Location 

The Get Predicted Location process (process 2.6) obtains the latitude and longitude for each 
shot from the predicted orbit file using common routines. The shot times are input, the pre- 
dicted orbit file is interpolated to get the spacecraft position vector for each shot time, and 
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then the latitude and longitude are computed from the position vector. The common routines 
c_intrpPOD and c_calc_sploc will be used for the calculations. The common routines will be 
called directly by the LI A Manager; it is not necessary to generate code for the Level 1A 
Computations subsystem. 
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GLASAlt is a core GSAS PGE. It uses the Waveform and Elevation subsystems to create 
GLAS Level IB and 2 data from the Level 1 GLAS altimetry data products (and optional L2 
atmosphere products). GLAS Alt will read the GLA01 fde created by GLAS L1 A to create 
the GLA05, GLA06, and GLA12-15 products. GLAS Alt can also read the GLA05 fde which 
it created in a separate processing scenario to create GLA06 and GLA12-15. Additionally, 
GLAS_Alt can read the GLA05 and GLA06 fdes created in a separate processing scenario to 
generate GLA12-15. 

10.1 Function 

GLAS_Alt encompasses both the Waveform and Elevation subsystems. 

The Level IB Waveforms subsystem computes the geo location and produces waveform-based 
information required to create the elevation products (GLA05). 

The Levels IB and 2 Elevation Computation subsystem generates all elevation Standard Data 
Products, associated Processing Quality Assessment data, and related computations. The 
Level IB subsystem creates parameters for a Level IB time-ordered global product (GLA06) 
with a geodetically corrected surface elevation using the same standard algorithm used for ice 
sheet regions. The Level 2 subsystem determines region specific (ice sheet, sea ice, land, and 
ocean regions) elevation parameters for Level 2 time-ordered regional products (GLA12, 
GLA13, GLAM, and GLA15). The presence of optional L2 Atmosphere products GLA09 and 
GLA11 cause atmosphere-specific parameters on GLA06 and 12-15 to be filled with data. 
Flags indicate the presence/absence of atmosphere data. 

10.2 Design Approach 

The following design criteria are specific to GLAS Alt 

• GLAS_Alt fully uses the standard routines from the model GSAS PGE. 

• GLAS Alt can perform partial processing. However, since the Elevations subsystem 
needs data from GLA05, it is not possible to create GLA12-15 with only GLA06 as an 
input. 

• The GLAS Alt Elevations process needs atmosphere values from GLA09 and 
GLA1 1 . This requires that the GLASAtm jobs for the corresponding time period be 
run before GLAS_Alt elevation jobs. (The GLAS_Alt Waveforms process can be run 
before GLAS Atm.) 

• All products are output at one record per 1 sec. However, GLA12-15 are only written 
when the footprint location falls within the respective regional mask. 

• Two ANC01 meteorological data sets corresponding to the 6-hour time periods sur- 
rounding the time of the output product data are required. 
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10.3 Input and Output Files 

Table 10-1 lists the required inputs to GLASAlt. Table 10-2 lists the outputs created by 
GLASAlt. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding these files. Those files which are only required by spe- 
cific subsystems are noted within the table. 


Table 10-1 GLAS_Alt Inputs 


File Spec 

Type 

Source 

Short Description 

anc01*.dat 

Dynamic Ancillary 

met_util 

Meteorological subset files. Data 
sets at times before and after the 
time of the profile are interpolated to 
the time of the profile. 

# anc04*.dat 

Dynamic Ancillary 

UTexas 

IERS Polar Motion and Earth Rota- 
tion Data File. 

anc07*_0000.d 

at 

Static Ancillary 

Science Team 

Error file. 

anc07*_0001.d 

at 

Static Ancillary 

Science Team 

Global constants file. 

anc07*_0003.d 

at 

Static Ancillary 

Science Team 

Waveform constants file. 
‘Waveform only 

anc07*_0004.d 

at 

Static Ancillary 

Science Team 

Elevations constant file. 
*Elevation only 

# anc08*.dat 

Dynamic Ancillary 

UTexas 

Precision Orbit file. 

# anc09*.dat 

Dynamic Ancillary 

UTexas 

Precision Attitude file. 

anc12*_0000.d 

at 

Static Ancillary 

Science Team 

Coarse DEM file 
‘Elevation only. 

anc12*_0001.d 

at 

Static Ancillary 

Science Team 

Fine DEM file 
‘Elevation only. 

anc13*.dat 

Static Ancillary 

Science Team 

Geoid file 
‘Elevation only. 

anc16*.dat 

Static Ancillary 

Science Team 

Load tide coefficients file 
‘Elevation only. 

anc17*.dat 

Static Ancillary 

Science Team 

Ocean tide coefficients file 
‘Elevation only. 

# anc20*.dat 

Static Ancillary 

Science Team 

Predicted Orbit 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion file. 

anc27*_0000.d 

at 

Static Ancillary 

Science Team 

Coarse regional mask file. 
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Table 10-1 GLAS_Alt Inputs (Continued) 


File Spec 

Type 

Source 

Short Description 

anc27*_0001.d 

at 

Static Ancillary 

Science Team 

Fine regional mask file. 

anc33*.dat 

Dynamic Ancillary 

Science Team 

UTC time conversion file. 

anc41*.dat 

Static Ancillary 

Science Team 

JPL Planetary Ephemeris 

anc45*_0001.d 

at 

Static Ancillary 

Science Team 

GLA01 metadata input file. 
‘Waveform only 

anc45*_0005.d 

at 

Static Ancillary 

Science Team 

GLA05 metadata input file. 

anc45*_0006.d 

at 

Static Ancillary 

Science Team 

GLA06 metadata input file. 

anc45*_0012.d 

at 

Static Ancillary 

Science Team 

GLA12 metadata input file. 

anc45*_0013.d 

at 

Static Ancillary 

Science Team 

GLA13 metadata input file. 

anc45*_0014.d 

at 

Static Ancillary 

Science Team 

GLA14 metadata input file. 

anc45*_0015.d 

at 

Static Ancillary 

Science Team 

GLA15 metadata input file. 

anc51*.dat 

Dynamic Ancillary 

SRTM_DEM 

SRTM DEM data files. 
‘Elevation only. 

anc52*_0001.d 

at 

Static Ancillary 

Science Team 

Range Saturation Correction table. 

anc52*_0002.d 

at 

Static Ancillary 

Science Team 

Energy Saturation Correction table. 

anc54*_0001.d 

at 

Static Ancillary 

Science Team 

GLAS-Derived 1km DEM over 
Greenland index file. 
‘Elevation only. 

anc54*_0002.d 

at 

Static Ancillary 

Science Team 

GLAS-Derived 1km DEM over 
Greenland data file. 

*Elevation only. 

anc54*_0003.d 

at 

Static Ancillary 

Science Team 

GLAS-Derived 500m DEM over Ant- 
arctica index file. 

‘Elevation only. 

anc54*_0004.d 

at 

Static Ancillary 

Science Team 

GLAS-Derived 500m DEM over Ant- 
arctica data file. 

‘Elevation only. 

anc54*_0005.d 

at 

Static Ancillary 

Science Team 

Canadian DEM index file. 
*Elevation only. 
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Table 10-1 GLAS_Alt Inputs (Continued) 


File Spec 

Type 

Source 

Short Description 

anc54*_0006.d 

at 

Static Ancillary 

Science Team 

Canadian DEM data file. 
‘Elevation only. 

anc55*.dat 

Static Ancillary 

Science Team 

Mean Sea Surface file. 
‘Elevation only. 

anc56*.dat 

Static Ancillary 

Science Team 

Pole tide file. 
*Elevation only. 

anc57*.dat 

Static Ancillary 

Science Team 

Global bathymetry file. 
‘Elevation only. 

anc58*.dat 

Static Ancillary 

Science Team 

Ground Track file. 
‘Elevation only. 

anc59*.dat 

Static Ancillary 

Science Team 

Pointing Mode Table. 

Control File 

Control 

ISIPS Operations 

Control file. 

gla01*_.dat 

Level-IA Product 

GLAS_L1A 

LI A Altimetry product file. 
‘Waveform only. 

gla05*_.dat 

Level-1 B Product 

GLAS_Alt 

LI B Waveform product file. 
*Elevation only. 

gla06*_.dat 

Level-1 B Product 

GLAS_Alt 

LI A Elevation product file. 
‘Elevation only. 

gla09*_.dat 

Level-2 Product 

GLAS_Atm 

L2 Atmosphere product file. 
‘Elevation only. 

glair_.dat 

Level-2 Product 

GLAS_Atm 

L2 Atmosphere product file. 
‘Elevation only. 


# GLAS_Alt may be run with either anc04, anc08, and anc09, or with anc20. anc20 is a predicted- 
orbit product whereas anc04/08/09 are precision POD/PAD products. The anc04/08/09 combina- 
tion will produce better geolocations. 
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Table 10-2 GLAS_Alt Outputs 


File Spec 

Type 

Destination 

Short Description 

gla05*.dat 

LI B Alt Product 

Arch i ve/G L AS_Alt 

The level 1 B waveform parameteriza- 
tion product file. Contains the output 
from the waveform characterization pro- 
cedure and other parameters required 
to calculate surface slope and relief 
characteristics. 

gla06*.dat 

L2 Alt Product 

Archive/GLAS_Alt 

LI B elevation data product file. Con- 
tains the surface elevation, surface 
roughness assuming no slope, surface 
slope assuming no roughness and geo- 
detic and atmospheric corrections for 
the range. 

gla12*.dat 

L2 Alt Product 

Archive 

L2 ice sheet altimetry product file. Con- 
tains the ice sheet elevation and eleva- 
tion distribution calculated from 
algorithms fine-tuned for ice sheet 
returns. 

gla13*.dat 

L2 Alt Product 

Archive 

L2 sea ice altimetry product file. Con- 
tains the sea ice freeboard and sea ice 
roughness calculated from algorithms 
fine-tuned for sea ice returns. 

gla14*.dat 

L2 Alt Product 

Archive 

L2 land altimetry product file. Contains 
the land elevation and land elevation 
distribution calculated from algorithms 
fine-tuned for land returns. 

gla15*.dat 

L2 Alt Product 

Archive 

L2 ocean altimetry product file. Contains 
ocean elevation and small-scale rough- 
ness calculated from algorithms fine- 
tuned for ocean returns. 

qap05*.dat 

LIB Alt Quality 

QA 

LI B waveform parameterization quality 
file. 

qap06*.dat 

L2 Alt Quality 

QA 

L2 elevation data quality file. 

qap12*.dat 

L2 Alt Quality 

QA 

L2 ice sheet altimetry quality file. 

qap13*.dat 

L2 Alt Quality 

QA 

L2 sea ice altimetry quality file. 

qap14*.dat 

L2 Alt Quality 

QA 

L2 land altimetry quality file. 

qap15*.dat 

L2 Alt Quality 

QA 

L2 ocean altimetry quality file. 

anc06*.dat 

Dynamic Ancillary 

ISIPS Operations 

Standard metadata/processing log file. 
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10.4 GLAS_Alt 

The basic GLASAlt processing algorithm is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (Print_Cntl) 

• Write version info (Write_LibVer, Write_AncVer) 

• Read ancillary files (ReadAnc) 

• Write execution flags information (Write_eCntl) 

• Until all data are processed... 

Input data to process (ReadData) 

- Execute the WF_Manager, based on Control 
Execute the Elev_Manager, based on Control 

• Close all files and generate summaries (Main Wrap) 

10.4.1 PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• Write_LibVer 

• ReadANC 

• Write_AncVer 

• ReadData 

• MainWrap 

10.5 Waveform Manager (WFMgr) 

The Waveform Manager controls execution of the waveform subsystem, passes variables 
from the input GLA01 product to the output GLA05 product, and handles granule start/stop. 
The manager controls execution of the waveform science algorithms based on flags received 
from GLAS Alt. The manager is only executed if at least one of its execution flags is set. 
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WFMgr is passed arrays of output file control structures and execution flags. It accesses prod- 
uct and algorithm data directly from the requisite public data structures. Execution flags are 
defined in eCntl_mod; file control structures defined in the fCntlmod component of the 
execlib, and product/algorithm data within the GLA01 and GLA05 components of the 
productlib. 

The first thing the manager does is check for an end-of-granule condition within each defined 
output file by comparing the nominal time of data (set by ReadData_mod) with the appropri- 
ate stop time within the specific file data structure. If an end-of-granule condition is detected, 
wrap-up and final QA routines are called and the product and QA files are closed. If another 
granule of the same type has been specified in the control file, the manager opens the appro- 
priate product and QA files and loops to verify the stop time of the new granule is greater than 
the nominal time of data. 

Next, the manager executes several science algorithms based on its execution flags and data 
availability. These algorithms are discussed in the WFSubsystem section. Each returns a flag 
indicating if the GLA05 data product should be written. Values which are passed directly from 
one product to another are set appropriately. 

QA routines are called to process QA information and the Write WF routine is called with the 
appropriate flags to write data to the product file. Before writing a record, WriteWF verifies 
that the appropriate output file exists and that the nominal time of data is greater than the start 
time specified in file control structure. If the nominal time is less than the start time, the data 
record is not written. An appropriate error message is written to ANC06 if a record is skipped. 

Figure 10-1 "WFMgr Structure Chart" provides an overview of the WFMgr and the subrou- 
tines it calls. 
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Figure 10-1 WFMgr Structure Chart 
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10.5.1 WFMgr Subprocesses 

WFGranulelnit Initialize all WF granules 
QAP05_granule_init Initializes QA arrays for GLA05 
WF_granule-check Checks ALT and ATM waveform granules for EOF 
WF_qap_check Checks WF QAP for wrapup 

Check WF APIDs Checks WF APIDs and sets availability flags appropriately 

C_SetCalibVars Initialize laser energy calibration coefficients 

Set Filtnum Sets filter number based on waveform type 

Flip WF Flips the waveforms 

Set_CompParm Sets digitizer from instrument state 

SetBias Stets bias and times due to delays and ANC09 correction 

SetPADParms Sets parameters derived from PAD 

GLAS_Error GSAS standard error reporting utility 

W Assess Major WF subroutine that performs a general assessment of the various 

aspects of the waveforms 

get_anc08_degrades Retrieves POD degradation data from anc08 file header 

get_anc09_degrades Retrieves PAD degradation data from anc09 file header 

c_Beam_Set_Ang Calculate laser coelevation, azimuth, and sun angle 

W FunctionalFt Major WF subroutine that calculates two (land plus “other”) functional 
least squares fits to a Gaussian for each waveform 

Write WF Writes a GLA05 WF record 
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10.6 Elevation Manager (Elev_Mgr) 

The Elevation Manager controls execution of the Elevation subsystems, passes variables from 
the input GLA05/06 product to the output GLA06 and GLA12-15 products, and handles gran- 
ule start/stop. The manager controls execution of the elevation science algorithms based on 
flags received from GLASAlt. The manager is only executed if at least one of its execution 
flags is set. Elev_Mgr is passed arrays of output file control structures and execution flags. It 
accesses product and algorithm data directly from the requisite public data structures. Execu- 
tion flags are defined in eCntlmod; file control structures defined in the fCntlmod compo- 
nent of the exec lib, and product/algorithm data within the GLA05/06 and GLA12-15 
components of the product_lib. 

The first thing the manager does is check for an end-of-granule condition within each defined 
output file by comparing the nominal time of data (set by ReadData_mod) with the appropri- 
ate stop time within the specific file data structure. If an end-of-granule condition is detected, 
wrap-up and final QA routines are called and the product and QA files are closed. If another 
granule of the same type has been specified in the control file, the manager opens the appro- 
priate product and QA files and loops to verify the stop time of the new granule is greater than 
the nominal time of data. 

After checking the granule times, processing begins. The manager calls common library geo- 
location and DEM routines to compute position and elevation and tide routines to get tide 
data. 

Next, the manager calls routines to check the surface type of the data and executes several sci- 
ence algorithms based on its execution flags and data availability. These algorithms are dis- 
cussed in the DFD section. Each returns a flag indicating if the appropriate data product 
should be written. Values which are passed directly from one product to another are set appro- 
priately. 

QA routines are called to process QA information and the WriteElev routine is called with the 
appropriate flags to write data to the product fdes. Before writing a record, WriteElev verifies 
that the appropriate output file exists and that the nominal time of data is greater than the start 
time specified in file control structure. If the nominal time is less than the start time, the data 
record is not written. An appropriate error message is written to ANC06 if a record is skipped. 

Figure 10-2 "ElevMgr Structure Charf'provides an overview of the ElevMgr and the subrou- 
tines it calls. 
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Figure 10-2 ElevMgr Structure Chart 
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10.6.1 ElevMgr Subprocesses 


Elev_Granule_lnit 

Initialize all elevations (6,12-15) granules 

Elev_granule_check 

Checks ALT and ATM waveform granules for EOF 

Elev_qa_check 

Checks Elevation QAP for wrapup 

avg_tp_data 

Checks WF APIDs and sets availability flags appropriately 

convert_ranges 

Convert GLA05 range from time units to distance 

Set_std_rng_params 

Set standard-fit range parameters on GLA06,12,13,15 from con- 
verted GLA05 ranges 

Set_alt_rng_params 

Set alternate-fit range parameters on GLA14 from converted 
GLA05 ranges 

StdFitComps 

Convert GLA05 standard fit parameters from time units to distance 
units and set corresponding GLA06,12,13,15 parameters 

AltFitComps 

Convert GLA05 standard fit parameters from time units to distance 
units and set corresponding GLA14 parameters 

SolarAngle 

Set GLA06 sun angle value from attitude and ephemeris 

SetAtmParams 

Propagate selected atmospheric parameters from GLA09 and 
GLA11 

AtmRefICorr 

Compute reflectivity correction 

PreGeoLoc 

Perform re-geolocation if called for or if POD has been re-interpo- 
lated 

getFirstLastValid 

Get first and last valid waveform indices 

ComputeGeoid 

Compute geoid elevations 

ComputeTrop 

Compute range corrections due to tropospheric conditions 

GetSurfType 

Compute surface-type flags based on location 

CalcSumCorrs 

Calculate the sum of all range corrections 

GeoLocStd 

Perform geolocation for standard waveform fit 

GeoLocAlt 

Perform geolocation for alternate waveform fit 

c_Azimuth_FootPrnt1 s 

Compute the azimuth of a 1 -second trace of the satellite footprint 
along the orbit track 

ComputeTideCorr 

Compute elevation corrections due to tidal forces 

CalcSatCorr 

Compute saturation corrections and set saturation correction flag 

SetElevFlags 

Sets an assortment of elevation-related flags based on data values 

Pass_GLA06 

Sets pass-through variables in GLA12-15 from GLA06 values 

Fetch_DEM_Vals 

Retrieve high resolution DEM elevation values 
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Elev_AT_QAP 

Update QAP along-track parameters for GLA06,12-15 

WriteElev 

Writes elevation record for GLA06.12-15 
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10.7 PGE/Manager Implementation Details 

This section discusses specific aspects of the PGE/Manager implementation which should be 
addressed in more detail. 

10.7.1 GLA05 Requirement 

The original concept of GLAS Alt was to enable the Elev_Mgr to create GLA12-15 directly 
from GLA06. However, due to data dependencies, GLA05 input is required (as well as 
GLA06) when creating GLA12-15. 

10.8 WF_Subsystem 

The Level IB Waveforms subsystem computes the geo location, and produces waveform- 
based information required to produce the elevation products (GLA05) 

The Level IB Waveforms subsystem is divided into two main processes (W_Assess, and 
WFunctionalFt) which generate waveform-based information required to produce the eleva- 
tion products (GLA05). A control flag (w ctrl) is passed to processes W Assess and 
W FunctionalFt indicating whether processing will be land algorithm only, other-than-land 
algorithm only, or both, and whether the subprocess W DetGeo will be called. In addition to 
producing waveform-based information, processes W Assess and W FunctionalFt generate 
QA data for inclusion in the summary information product. 

10.8.1 Assess Waveforms (W_Assess) 

W Assess performs a general assessment of the waveforms including: a check for saturation; 
calculating various shape characteristics; preliminary uncorrected latitude, longitude, and ele- 
vation; reflectance; and calculating the reference range, minimum range offset (signal begin), 
preliminary uncorrected range offset (signal end), and the threshold retracker range offset. 

Input arguments: 


w_ctrl 

l_PADflag 

i_numWFinFrame 

i_numGinWF 

r_wf_trans 

r_wf_rec 

i_wf_rec 

i_cr 

i_ndxCr 
d_bgNoiseOb 
d sDevNsOb 


Control flags 

Indicates if the PAD file is being used (same as g_havePAD) 

Number of WF in a frame (normally 40) 

Number of gates in WF (either 200, or 544) 

Transmitted pulse in volts 
Received WF in volts 
Received WF in raw counts 
Compression values 

Gate index where second compression starts 

Mean background noise level as measured by instrument 

Standard deviation of background noise level calculated by the on-board 
algorithm 
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d_FilterOb 

d_TimeGate1Tr 

d_TimeGateLRec 

dJJTCIstPTime 

d_dShotTime 

d_PADpntgVect 

d_areaTele 

d_optTrans 

d_nrgRec 

d_gain_recv 

d_gainTr 

d_nrgTr 

anc_param_d 

anc_param_indep 

d_dTHiRes 

i_implement33_Ndx 

i_gval_rcv 

d_RecNrgAII_EU 

d_rDelay_digtzr 

d_plRbias 

dJatPreUncor 

dJongPreUncor 

d_elevPreUncor 

i_elvFlg 

l_RcorrFlglnt 

l_RcorrFlgPL 

LWfqual 


Output arguments: 


Filter width where instrument found signal (ns) 

Digitizer time of gate 1 of transmitted pulse (ns) 

Digitizer time of last gate of received WF (ns) 

UTC of 1st transmitted pulse (sec) 

Time increment from d_UTC1stPTime for shots 2-40 (microsec) 
Precision attitude pointing vector 
Telescope Area (-0.709 m A 2) 

Optics Transmission 
Energy of received WFs 
Received gain 
Transmitted gain 
Energy of transmitted pulses 

Dependent Ancillary parameters (land or other-than-land processing) 
Independent Ancillary parameters 
Time in ns of one digitizer gate 

Shot where d_rDelay_digtzr, d_plRbias, and d_dTHiRes change 

Received gain in raw counts 

Echo pulse energy 

Prelaunch internal range delay in ns 

Post launch range bias in ns 

Preliminary uncorrected latitude 

Preliminary uncorrected longitude 

Preliminary uncorrected elevation 

Source of elevation indicator flag 

FALSE=d_rDelay_digtzr not applied 

FALSE=d_plRbias not applied 

An array of 31 flags for each waveform. These flags include: no signal, 
no leading edge, no trailing edge, no transmitted pulse, land, ocean, 
icesheet, seaice, no fit, noise and standard deviation of noise are calcu- 
lated, maximum iterations during fit, region selected for waveform fit, and 
invalid waveform. 
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dJatPreUncor 

dJongPreUncor 

d_elevPreUncor 

i elvFIg 

l_RcorrFlglnt 

l_RcorrFlgPL 

LWfqual 


d_dDigComp 
d relTime 


d_wf_sm 

d_maxSmAmp 

d_pcntSat 

d_bg_Noise 

d sDevNoise 


d_refRng 

d_maxRngO 

d_minRngOff 

d_preRngOff 
d_thRtkRngOff 
i_ndxBegin 
i_ndxEnd 
d areaRecWF 


Preliminary uncorrected latitude 
Preliminary uncorrected longitude 
Preliminary uncorrected elevation 
Source of elevation indicator flag 
FALSE=d_rDelay_digtzr not applied 
FALSE=d_plRbias not applied 

An array of 31 flags for each waveform. These flags include: no signal, no lead- 
ing edge, no trailing edge, no transmitted pulse, land, ocean, icesheet, seaice, 
no fit, noise and standard deviation of noise are calculated, maximum iterations 
during fit, region selected for waveform fit, and invalid waveform. 

Offset of last gate of received WF from last digitized gate last received gate 
time is not same as last digitized gate time if there is compression 

Relative time of each gate in ns from gate 1 (earliest time) of received WF tak- 
ing account of the compression information. For example, if the original gates 
were one nanosecond apart, and there was a compression ratio of 2, then the 
time of gate 1 (r_wf_rec[1]) would be the average of the times of the first two 
digitizer gates ((0+1 )/2 or 0.5), and the time of gate 2 would be the average of 
the times of the third and fourth digitizer gates ((2+3)/2 or 2.5). 

Smoothed WF 

Maximum amplitude of smooth WF 
Percent saturation of WF - set to invalid 

Either the observed noise (d_bgNoiseOb), or the calculated background noise. 
The calculation is performed if anc07%i_nsCal is set, or if the observed noise is 
zero or invalid and the waveform is not invalid. 

Either the observed noise standard deviation (d_sDevNsOb), or the standard 
deviation of the calculated noise. The calculation is performed if 
anc07%i_nsCal is set, or if the observed noise is zero or invalid and the wave- 
form is not invalid. 

Reference range in ns - time from Tr pk to last gate 

Offset to be added to d_refRng to give the time of the last threshold crossing 
(closest to the ground, signal end) 

Offset to be added to d_refRng to give the time of the first threshold crossing 
(closest to the spacecraft, signal begin) 

Same as d_maxRngOff 

Offset to be added to d_refRng to give the retracker threshold range 
Index of beginning of signal 
Index of end of signal 

Area of signal return of r_wf_rec from sig begin to sig end 
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d_maxRecAmp 

d_skew 

d_kurt 

d_centroid 

d_maxTrAmp 

d_areaTr 

dJocTr 

d_tx_sm 

d_minTxAmp 

d_trTime 

i_ndxTrB 

i_ndxTrE 

d_sDevNsTx 

d_nsTx 

d_skewTr 

d_PODposVect 

d_reflctUncorr 

d_reflctAIIUnc 

d_centroidlnstr 

l_PODflag 

l_offNadirFlag 

i_usePAD 

Hand 

l_ocean 

IJcesheet 

l_seaice 

l_badFrame(1) 

l_badFrame(2) 

i_errSe verity 


Maximum amplitude of recieved WF 
Skewness of r_wf_rec from sig begin to sig end 
Kurtosis of r_wf_rec from sig begin to sig end 
Centroid of r_wf_rec from sig begin to sig end 
Maximum amplitude of transmitted pulse 
Area of gaussian fitted to transmitted pulse 
Centroid of transmitted pulse (ns) 

Smoothed transmitted pulse 

Min amp for transmitted pulse 

Relative time of each gate in ns of transmitted pulse 

Index of beginning of transmitted pulse 

Index of end of transmitted pulse 

Std dev of noise for transmitted pulse 

Noise for transmitted pulse 

Skewness of transmitted pulse gaussian 

Precision orbit position vector 

Reflectivity, not corrected for atmosphere, calculated using the received energy 
from the maximum peak 

Reflectivity, not corrected for atmosphere, calculated using the received energy 
from all peaks 

Instrument centroid of last peak 

Returned by CJntrpPOD, indicates the status of the orbit information 
Returned by C_CalcSpLoc, indicates if the spacecraft is pointed off nadir. 

From C_CalcSpLoc, array indicating if PAD used for each shot 

True indicates the possible presence of land 

True indicates the possible presence of ocean 

True indicates the possible presence of icesheet 

True indicates the possible presence of seaice 

True if all WFs in this record have no signal 

False if all WFs in this record are valid 

Error flag from CJntrpPOD, C_GetRegions, C_CalcTNrg, or C_CalcSpLoc 
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10.8.1.1 W_Assess Subprocesses 

W_Assess calls the following subprocesses: 


W_CalcRelTime 

Calculates the d_relTime array 

W_CharTrPulse 

Characterize the transmitted pulse 

W_CalcNoise 

Calculates the noise 

W_CalcRefRng 

Calculates the reference range 

W_SmoothPreRC 

Smooth the WF's with a gaussian filter 

W_DetGeo 

Determine the geolocation of each shot 

C_GetRegions 

Determines the region types of each shot 

W_CalcCtMxArAs 

Calculates centroid, maximum amplitude, area, skew & kurtosis for the WF 
between signal_begin (i_ndxBegin) & signal_end (i_ndxEnd) 

W_CalclnstrCt 

Calculates the instrument centroid of the maximum amplitude peak 

W_Ck4Sat 

Check for waveform saturation 

W_CalcThRetrkr 

Calculates offset of retracker threshold 

C_CalcTNrg 

Calculates the transmitted energy 

W_CalcReflct 

Calculates reflectance 

10.8.1.2 Calculate the WF Functional Fit (W_FunctionalFt) 

WFunctionalFt calculates two functional fits for each waveform, one for land and one for all 
other surface types. Various fit related parameters are returned including the initial number of 
potential peaks found, the number of gaussian peaks (as many as six for the alternate or land 
fit, and up to two for the standard fit), the standard deviation of fit, and flags indicating satura- 
tion, whether the maximum number of iterations was exceeded, or if there was a fit. 

Input arguments: 


w_ctrl 

Control flags 

i_numWFinFrame 

Number of WF in a frame (normally 40) 

i_numGinWF 

Number of gates in WF (either 200, or 544) 

r_wf_rec 

Received WF in volts 

d_wf_sm 

Smoothed WF 

r_wf_trans 

Transmitted pulse in volts 

d_tx_sm 

Smoothed transmitted pulse 

d_minTxAmp 

Min amp for transmitted pulse 

d_sDevNsTx 

Std dev of noise for transmitted pulse 
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d_nsTx 
d relTime 


i_ndxBegin 

i_ndxEnd 

d_bg_Noise 

d sDevNoise 


Hand 

l_ocean 

IJcesheet 

l_seaice 

d_UTCtime 

dJatPreUncor 

dJongPreUncor 

d_elevPreUncor 

d_centroid 

d_dDigComp 

anc_param_dep 

anc_param_indep 

LWfqual 


Noise for transmitted pulse 

WF taking account of the compression information. For example, if the origi- 
nal gates were one nanosecond apart, and there was a compression ratio of 
2, then the time of gate 1 (r_wf_rec[1]) would be the average of the times of 
the first two digitizer gates ((0+1 )/2 or 0.5), and the time of gate 2 would be 
the average of the times of the third and fourth digitizer gates ((2+3)/2 or 2.5). 

Index of beginning of signal 

Index of end of signal 

Either the observed noise (d_bgNoiseOb), or the calculated background 
noise. The calculation is performed if anc07%i_nsCal is set, or if the observed 
noise is zero or invalid and the waveform is not invalid. 

Either the observed noise standard deviation (d_sDevNsOb), or the standard 
deviation of the calculated noise. The calculation is performed if 
anc07%i_nsCal is set, or if the observed noise is zero or invalid and the 
waveform is not invalid. 

True indicates the possible presence of land 

True indicates the possible presence of ocean 

True indicates the possible presence of icesheet 

True indicates the possible presence of seaice 

UTC time - used only for debug not for calculations 

Preliminary uncorrected latitude 

Preliminary uncorrected longitude 

Preliminary uncorrected elevation 

Centroid of r_wf_rec from sig begin to sig end 

Offset of last gate of received WF from last digitized gate last received gate 
time is not same as last digitized gate time if there is compression 

Dependent Ancillary parameters 

Independent Ancillary parameters 

An array of 31 flags for each waveform. These flags include: no signal, no 
leading edge, no trailing edge, no transmitted pulse, land, ocean, icesheet, 
seaice, no fit, noise and standard deviation of noise are calculated, maximum 
iterations during fit, region selected for waveform fit, and invalid waveform. 
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Output arguments: 


LWfqual 


d_estTxParms 

d_parmTr 

d_sDevFitTr 

d_solnTrSgms 

d_parm 

i_n Peaks 
d_estParms 
i_nPeaklnit 
i_rank 

d_solnSigmas 

d_wfFitSDev 

l_fit_nogo 

l_fit_maxiter 

i_errSeverity 


An array of 31 flags for each waveform. These flags include: no signal, no 
leading edge, no trailing edge, no transmitted pulse, land, ocean, icesheet, 
seaice, no fit, noise and standard deviation of noise are calculated, maximum 
iterations during fit, region selected for waveform fit, and invalid waveform. 

Estimated parameters for fit of transmitted pulse 

Noise, amplitude, centroid, and sigma of transmitted pulse gaussian 

Standard deviation of fit of d_parmTr to transmitted pulse 

Sigmas of fit of d_parmTr to transmitted pulse 

noise, 6x(amplitude,loc, sigma). Within this subsystem, Iocs are relative to 
gate 1 , just before returning to WFMgr, they are converted to offsets that are 
to be added to the reference range. 

Actual number of peaks in d_parm 

Estimated parameters before the fit 

Number of peaks initially found before the fitting process 

Rank of peaks 

Solution sigmas for each parameter in d_parm 
std deviation of fit 

True if fit process was not completed 

True if fit process was stopped after maxiter iterations 

Error flag from WJnvertM in W_LsqFit 
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10.8.1.3 W_FunctionalFt Subprocesses 

WFunctionalFt calls the following subprocesses: 

W_Param With Fit Calculates the maximum amplitude for each WF, and over- 

sees the fitting process for first the alternate set of parame- 
ters, and then the standard set of parameters. 

W_Ck4HiSat Determines the saturation type, if any, for each WF 

W ParamWithFit calls the following subroutines: 

W_EstParams Estimates the WF model parameters for W_ParamWithFit 

W_PerformFit Fit the gaussian functions to the recieved waveforms 

W RankAIIPeaks 


WEstParams calls the following subroutines: 


W Calc2ndDer 


Calculates the second derivatives of the WF's 


W_Estimates Determines the initial number of peaks in the WF. Combine 

peaks until there are no more than i_maxfit and make 
parameter estimates 

W_EstNew Determine the number of peaks in the WF. Combine close 

peaks, then choose the largest l_maxfit peaks and make 
parameter estimates. 


WEstimates calls the following subroutines: 


W_combinePeak 
W_combinePeaks 
W RankPeaks 


Combines one peak with the following peak 
Combines multiple peaks 
Assign a rank to each peak 


W PerformFit calls the following subroutines: 


W_LsqFit Perform least squares fit for one WF 

W_RmPeaks Remove peaks 

W_combinePeaks Combines multiple peaks 


W modPnW 


W NormWF 


Modify estimated amplitude for maxAmp, and modify the 
weights so that a better fit to the leading edge will be pre- 
ferred 

Normalize waveform 
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W_UnNormWF Un-normalize waveform 

W_CalcSDev Calculate goodness of fit 

WLsqFit calls the following subroutines: 


W_CkParms 

Check the waveform parameters for unreasonable values 

W_CalcFnP 

Calculate the value of the function and the partial derivatives 
with respect to the function parameters 

W_CalcArP 

Calculate the area and the partial derivatives of the area 
with respect to the function parameters 

WJnvertM 

Invert iDim x iDim matrix A 

W_CkConv 

Check the waveform parameters for convergence 

W_CalcSDev 

Calculate goodness of fit 


10.9 Elev_Subsystem 

The Levels IB and 2 Elevation Computation subsystem generates all elevation Standard Data 
Products, associated Processing Quality Assessment data, and related computations. The 
Level IB subsystem creates parameters for a Level IB time-ordered global product (GLA06) 
with a geodetically corrected standard elevation. The Level 2 subsystem determines region 
specific (ice sheet, sea ice, land, and ocean regions) elevation parameters for Level 2 time- 
ordered regional products (GLA12, GLA13, GLA14, and GLAS15). 

10.9.1 LI B DFDs and their Descriptions 

Below is a breakdown of each of the elevation processes into subprocesses. Each subprocess 
corresponds to a Fortran 90 subroutine that is called by the elevation manager. 

10.9.1.1 Calculate Coelev, Azimuth & Sun Angle (C_Beam_Sun_Ang) 

Calculate the laser beam coelevation and azimuth and sun angle given the geodetic lat, Ion, 
height above ellipsoid and time. 

10.9.1.2 Interpolate POD (CJntrpPOD) 

Utilizes the POD file (ANC08), and time to interpolate the precision vectors for use in geolo- 
cation. 

10.9.1.3 Tide Correction Routines (E_CalcLoadTD, E_CalcOceanTD, 
E_CalcEarthTD) 

The tide correction routines consists of three processes which calculate the elevation correc- 
tions due to the effects of the load tide, ocean tide, and earth tide. Each process is triggered by 
a control flag. Following is a brief description of each of the process: 
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10.9.1.3.1 Compute Load Tide Correction (E_calcLoadTd) 

Utilizes the load tide coefficients file to compute the coefficients for the given spot location. 
Then calculates the load tide correction using the given time. 

10.9.1.3.2 Compute Ocean Tide Correction (E_calcOceanTd) 

Utilizes the ocean tide coefficients file to compute the coefficients for the given spot location. 
Then calculates the ocean tide correction using the given time (time). 

10.9.1.3.3 Compute Earth Tide Correction (E_calcEarthTd) 

Utilizes the earth tide coefficients file to compute the coefficients for the given spot location. 
Then calculates the earth tide correction using the given time. 

10.9.1.4 Calculate Std surface Elevation and spot loc (C_CalcSploc) 

Utilizes the results from the previous three processes along with the spacecraft position in 
ITRF (Inertial Terrestrial Reference Frame), the laser attitude in ITRF, reference range, and 
ice sheet range offset to calculate surface independent elevation and spot location. 

10.9.1.5 Interpolate Geoids (C_GetGeoid) 

Utilizes the spot location to interpolate for the geoid height at that location. This is a common 
routine used by several processes. 

10.9.1.6 Calculate Troposphere Corrections (E_CalcTrop) 

Utilizes the met data files, spot location, and elevation (with respect to the geoid), to interpo- 
late spatially for parameters used in the calculation of the tropospheric corrections. These cor- 
rections are then temporally interpolated to get the tropospheric corrections for the given time. 

10.9.1.7 Calculate Angle (C_CalcAngle) 

Calculates the angle between the POD and range vectors. 

10.9.1.8 10.9.1.8 Identify Regions (C_GetRegions) 

Utilizes the region masks file and spot location to determine the valid regions for the spot 
location 

10.9.1.9 10.9.1.9 Interpolate DEM (E_CalcDEM) 

Utilizes the spot location, the Global DEM file, and the DEM mask file to determine the DEM 
elevation for the specified spot. 

10.9.1.10 10.9.1.10 Calculate Slope & Roughness (E_CalcSlope) 

Utilizes the sigma of the gaussian waveform, transmitted pulse width, and receiver impulse 
width to calculate the slope and roughness. 

10.9.1.11 Create LIB Quality Statistics (update_GLA06QA) 

Combines QA data from the previous six processes to create QA statistics for the Level IB 
Elevation Computation subsystem 
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10.9.1.12 10.9.1.12 Create LIB Quality Statistics 

Combines QA data from the previous six processes to create QA statistics for the Level IB 
Elevation Computation subsystem 

10.9.2 L2 DFDs and their Descriptions 

Below is a breakdown of each of the elevation processes into subprocesses. Each subprocess 
corresponds to a Fortran 90 subroutine that is called by the elevation manager 

10.9.2.1 Calc Reg Params (E_OceanParm, E_LandParm) 

Calculates the region specific parameters that have not already been determined earlier by the 
other routines. 

10.9.2.2 Create L2 Elevations QA (update_GLA12QA, update_GLA13QA, 
update_GLA14QA, update_GLA15QA) 

Combines QA data from the processes 5.2.2, 5.2.3, and 5.2.4 to create QA statistics for the 
Level 2 Elevation Computation subsystem. 

10.9.2.3 Create Elevation QA Statistics (wrapUpQAP06, wrapUpQAP12_15) 

Wraps up and writes to file the QA Statistics for the Level IB and 2 Elevation Computation 
subsystems. WrapUpQAP06 will handle the Level IB subsystem, while wrapUPQAP12_15 
will handle the Level 2 subsystem. 
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11.1 Overview 

GLAS_Atm is a core GSAS PGE. It uses the Atmosphere subsystem to create GLAS Level 
IB and 2 data from the Level 1 GLAS atmosphere data products. GLAS_Atm will read the 
GLA02 fde created by GLASL1 A and the ANC36 file created by Atm Anc to create the 
GLA07-11 products. 

11.2 Function 

The function of the Levels IB and 2 Atmosphere Computations subsystem is to create atmo- 
sphere parameters for the standard data products GLA07-11 and to generate associated meta- 
data and quality assessment (QA) data. 

11.3 Design Approach 

The following design criteria are specific to GLASAtm 

• GLAS_Atm fully uses the standard routines from the model GSAS PGE. 

• GLAS_Atm can perform partial processing. However, due to the 20 second buffering, 
the Level 2 data is always processed together even under reprocessing scenarios. Data 
products GLA08-11 are always created together. 

• The Level IB product (GLA07) is output at one record per 1 sec. 

• The processing of Level 2 data is buffered for 20 seconds irrespective of time gaps 
between data records. 

• The Level 2 products (GLA08-1 1) are output at one record per 4 seconds. 

• Cloud products are reported at once per 4 seconds, 1 second, and 5 Hz from 21 to 0 
km, and at 40 Hz below 10 km. 

• Aerosol products are reported at once per 4 seconds from 21 to 0 km and at once per 
20 sec from 41 to 21 km. 

• Twenty second averaging requires that at least ten seconds of valid profiles are avail- 
able. Likewise, four second averaging requires that at least two seconds of valid pro- 
files are available. 

• Met data sets at times before and after the time of the profile are interpolated to the 
time of the profile. If either of the met data sets are missing, then the available met 
data set is used without interpolation. If no met data sets are available, then standard 
atmosphere data are used instead 
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11.4 Input and Output Files 

Table 11-1 lists the required inputs to GLAS_Atm. Table 11-2 lists the outputs created by 
GLASAtm. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files.. 


Table 11-1 GLAS_Atm Inputs 


File Spec 

Type 

Source 

Short Description 

anc01*.dat 

Dynamic Ancillary 

met_util 

Meteorological subset files. 
Data sets at times before and 
after the time of the profile are 
interpolated to the time of the 
profile. If either of the ANC01 
data sets are missing, then the 
available ANC01 data set is 
used without interpolation. If no 
ANC01 data sets are available, 
then standard atmosphere data 
are used instead. 

anc04*.dat 

Dynamic Ancillary 

UTexas 

IERS Polar Motion and Earth 
Rotation Data File. 

anc07*_0000.dat 

Static Ancillary 

Science Team 

Error file. 

anc07*_0001.dat 

Static Ancillary 

Science Team 

Global constants file. 

anc07*_0002.dat 

Static Ancillary 

Science Team 

Atm constants file. 

anc07*_0005.dat 

Static Ancillary 

Science Team 

L1A constants file. 

anc08*.dat 

Dynamic Ancillary 

UTexas 

Precision Orbit file. 

anc09*.dat 

Dynamic Ancillary 

UTexas 

Precision Attitude file. 

anc12*_0000.dat 

Static Ancillary 

Science Team 

DEM file. 

anc12*_0001.dat 

Static Ancillary 

Science Team 

DEM mask file. 

anc13*.dat 

Static Ancillary 

Science Team 

Geoid file. 

anc18*.dat 

Static Ancillary 

Science Team 

Standard atmosphere file. 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion file. 

anc30*.dat 

Static Ancillary 

Science Team 

Global aerosol categorization 
map file. 

anc31*.dat 

Static Ancillary 

Science Team 

Aerosol tropospheric classifica- 
tion map file. 

anc33*.dat 

Dynamic Ancillary 

Science Team 

UTC time conversion file. 

anc35*.dat 

Static Ancillary 

Science Team 

Ozone file. 

anc36*.dat 

Dynamic Ancillary 

atm_anc 

Atmosphere Calibration file. 
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Table 11-1 GLAS_Atm Inputs (Continued) 


File Spec 

Type 

Source 

Short Description 

anc38*.dat 

Static Ancillary 

Science Team 

Multiple-scattering table file. 

anc45*_0002.dat 

Static Ancillary 

Science Team 

GLA02 metadata input file. 

anc45*_0007.dat 

Static Ancillary 

Science Team 

GLA07 metadata input file. 

anc45*_0008.dat 

Static Ancillary 

Science Team 

GLA08 metadata input file. 

anc45*_0009.dat 

Static Ancillary 

Science Team 

GLA09 metadata input file. 

anc45*_0010.dat 

Static Ancillary 

Science Team 

GLA10 metadata input file. 

anc45*_001 1.dat 

Static Ancillary 

Science Team 

GLA11 metadata input file. 

Control File 

Control 

ISIPS Operations 

Control file. 

gla02*_.dat 

Level-1 A Product 

GLAS_L1A 

LI A Atmosphere product file. 

gla05*_.dat 

Level-1 B Product 

GLAS_Alt (wf) 

LIB Waveform product file. 


Table 11-2 GLAS_Atm Outputs 


File Spec 

Type 

Destination 

Short Description 

gla07*.dat 

LIB Atm Product 

Archive 

LI B Global Backscatter product 
file. Contains full 532 nm and 
1064 nm calibrated attenuated 
backscatter profiles at 5 times 
per second, and from 10 to -1 
km, at 40 times per second. 
Also included will be calibration 
coefficient values and molecular 
backscatter profiles at once per 
second. 

gla08*.dat 

L2 Atm Product 

Archive 

L2 Planetary Boundary Layer 
and Elevated Aerosol Layer 
Height product file. Contains 
elevated aerosol layer height 
data consisting of top and bot- 
tom heights for up to 5 aerosol 
layers below 20 km at once per 
4 seconds, and top and bottom 
heights for up to 3 aerosol lay- 
ers above 20 km at once per 20 
seconds. 
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Table 11-2 GLAS_Atm Outputs (Continued) 


File Spec 

Type 

Destination 

Short Description 

gla09*.dat 

L2 Atm Product 

Archive 

L2 Cloud Layer Height product 
file. Contains top and bottom 
heights for up to 1 0 layers below 
20 km at once per 4 seconds, 
once per second, 5 times per 
second, and 40 times per sec- 
ond (below 4 km only). Ground 
heights will also be provided at 
each resolution. 

gla10*.dat 

L2 Atm Product 

Archive 

L2 Aerosol Vertical Structure 
product file. Contains cloud and 
aerosol backscatter and extinc- 
tion cross section profiles. 

glair.dat 

L2 Atm Product 

Archive 

L2 Thin Cloud/Aerosol product 
file. Contains optical depths for 
clouds for up to 10 layers, the 
planetary boundary layer, and 
aerosols for up to 8 layers. 

qap07*.dat 

L2 Atm Quality 

QA 

LIB Global Backscatter quality 
file. 

qap08*.dat 

L2 Atm Quality 

QA 

L2 Planetary Boundary Layer 
and Elevated Aerosol Layer 
Height quality file. 

qap09*.dat 

L2 Atm Quality 

QA 

L2 Cloud Layer Height quality 
file. 

qap10*.dat 

L2 Atm Quality 

QA 

L2 Aerosol Vertical Structure 
quality file. 

qapllfdat 

L2 Atm Quality 

QA 

L2 Thin Cloud/Aerosol quality 
file. 

anc06*.dat 

Dynamic Ancillary 

ISIPS Operations 

Standard metadata/processing 
log file. 


11.5 Functions 

shows the top-level structure chart of GLAS_Atm. The basic processing algorithm is summa- 
rized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 


Version 6.0 


Page 1 1 -4 


March 2013 






GLAS Atm 


The GLAS Science Algorithm Software Detailed Design Document 


• Print the control file (Print_Cntl) 

• Write version info (WriteLibVer, Write_AncVer) 

• Read ancillary files (ReadAnc) 

• Write execution flags information (Write_eCntl) 

• Until all data are processed... 

Input data to process (ReadData) 

- Execute the Atm Manager 
Close all files and generate summaries (Main Wrap). 



Figure 11-1 GLAS_Atm Structure Chart 
11.5.1 PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• WriteLibVer 

• ReadANC 

• WriteAncVer 

• Write eCntl 
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• ReadData 

• MainWrap 

11.5.2 Atm Manager (Atm_Mgr) 

The Atm Manager controls execution of the Atmosphere subsystem, passes variables from the 
input GLA02 product to the output GLA07-1 1 products, and handles granule start/stop. The 
manager controls execution of the science algorithms based on flags received from 
GLASAtm. Figure 11-2 shows the Atm_Mgr structure chart. 


FGE Core Routines 

glaXX_hdr_init 
g laXX_hdr_updale 
glaXX hdr strip 
comjhdnupdate 
Wn(e_g1aXX_hdr 
GLAS Error 


A cal cols 


CjntrpPOD 


C_CalcSploc 


0 GelGeoid 


C Calc UtM 


gei_anct>3_deQrades 
ge1_anct)9_degrades 
c_E3eam_S un_Angle 


c_G&t_R®giiQn3 


A_interp_met 


A mbscs 



QAP Routines 

GAP Version 
QAPXX Interface 


Met Dais Retrieve 

A_Fetch_Met_Con_N 
A_Fetch Met_Con _S 
A_Fetch_Met_Con_L 
A Fetch Met Con M 


A rebn lid 


A tecs 


Write Atm 


A buff data 


A_cld_lays 


A_lays_1 064 


A_cld_lay_1Q64_4Qhz 


A_pbl_lay 


A_aer_lays 


A_aer_Qpt_prop 


Figure 11-2 Atm_Mgr Structure Chart 
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Figure 11-3 shows a flow chart of the Atm Manager.. 



Figure 11-3 ATM Manager - Part 1 
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Atm_Mgr is passed arrays of output file control structures and execution flags. It accesses 
product and algorithm data directly from the requisite public data structures. Execution flags 
are defined in eCntlmod; file control structures defined in the fCntlmod component of the 
execlib, and product/algorithm data within the GLA02 and GLA07-11 components of the 
productlib. 

The first thing the manager does is check for an end-of-granule condition within each defined 
output file by comparing the nominal time of data (set by ReadData_mod) with the appropri- 
ate stop time within the specific file data structure. If an end-of-granule condition is detected, 
wrap-up and final QA routines are called and the product and QA files are closed. If another 
granule of the same type has been specified in the control file, the manager opens the appro- 
priate product and QA files and loops to verify the stop time of the new granule is greater than 
the nominal time of data. 

After checking the granule times, processing begins. The manager calls A_cal_coefs to get 
calibration coefficients from ANC36. It then calls common library geolocation and DEM rou- 
tines to compute position and elevation and Ainterpmet to get meteorological data. 

Next, the manager buffers the data and executes several science algorithms based on its exe- 
cution flags and data availability. These algorithms are discussed in the DFD section. Each 
returns a flag indicating if the appropriate data product should be written. Values which are 
passed directly from one product to another are set appropriately. 

QA routines are called to process QA information and the WriteAtm routine is called with the 
appropriate flags to write data to the product files. Before writing a record, WriteAtm verifies 
that the appropriate output file exists and that the nominal time of data is greater than the start 
time specified in file control structure. If the nominal time is less than the start time, the data 
record is not written. An appropriate error message is written to ANC06 if a record is skipped. 

11.6 Atm_Subsystem 

The function of the ATM LIB Calculate Calibration Coefficients, Profile Locations, and DEM 
process is to geolocate the lidar data, calculate the range of the satellite to the geoid height, 
compute the DEM elevation for the profile location, and compute the 532 nm and 1064 nm 
calibration coefficients. 

The function of the ATM LIB Calculate Backscatter Cross Section Profiles process is to cre- 
ate parameters for the Level lb Global Backscatter Data Product GLA07 including meteoro- 
logical profiles and 532 nm and 1064 nm attenuated backscatter cross section profiles. 

The function of the ATM LIB Create QA Statistics and Write ATM process is to create Level 
IB granule QA statistics, write the QAP07 QA product files, and write the GLA07 data prod- 
uct files. 

The function of the ATM L2 Buffer 20 Seconds process is to buffer 20 seconds of Level lb 
data for input into the level 2 processes. The processing of Level 2 data is buffered for 20 sec- 
onds irrespective of time gaps between data records. 

The function of the ATM L2 Calculate Layer Heights process is to create parameters for the 
Level 2 Global Planetary Boundary Layer and Elevated Aerosol Layer Heights Product 
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GLA08 and the Level 2 Global Cloud Heights for Multi-layer Clouds Product GLA09. This 
process determines, at several resolutions, the top and bottom elevations of multiple cloud and 
aerosol layers, ground detection heights, and the planetary boundary layer (PBL) height. 

The function of the ATM L2 Calculate Optical Properties process is to create parameters for 
the Level 2 Global Aerosol Vertical Structure Data Product GLA10 and the Level 2 Global 
Thin Cloud and Aerosol Optical Depths Data Product GLA11. This process creates cloud and 
aerosol backscatter cross section profdes and extinction cross section profdes. Optical depths 
for multiple cloud and aerosol layers and the planetary boundary layer are also created. 

The function of the ATM L2 Create QA Statistics and Write ATM process is to create Level 2 
granule QA statistics, write the QAP08-11 QA product files, and write the GLA08-11 data 
product fdes 


control 532 lidar 1064 lidar 


control 
LIB data 



Figure 11-5 Atmosphere Subsystem Processes 


11 .6.1 DFDs and their Descriptions 

Below is a breakdown of each of the atmosphere processes into subprocesses. Each subpro- 
cess corresponds to a Fortran 90 subroutine (name in parentheses) that is called by the atmo- 
sphere manager. Below are general comments: 

• Subprocesses do not call each other, but are called in turn by the atmosphere manager 
(AtmMgr) which is itself a subroutine. Therefore data are passed as arguments 
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between subprocesses. Likewise, data products are written by a separate subprocess 
and not by the subprocesses creating the output data. 

• Only subprocesses directly called by the atmosphere manager are shown in the dia- 
grams. 

• Each subprocess that shows a dotted control line in the diagram is under control which 
means that it is only selectively called by the atmosphere manager based upon the pro- 
cessing scenario selected in an input control file. 

• Each subprocess calls a common error routine (GLAS_Error) when an error condition 
occurs. Depending on the severity of the error, the processing may continue or stop, 
but in any case, all error messages are written to a common ancillary log file (ANC06). 

11.6.1.1 ATM LIB Calculate Calibration Coefficients, Profile Locations, and 
DEM Subprocesses 

The ATM LIB Calculate Calibration Coefficients, Profile Locations, and DEM process is 
divided into five subprocesses. Following is a description of each subprocess: 


control control PAD_angle 



Figure 11-6 ATM LIB Calculate Calibration Coefficients, Profile Locations, and DEM 

Subprocesses 

11.6.1.1.1 ATM LIB Calculate Calibration Coefficients (A_cal_cofs) 

Reads a file containing the entire granule's worth of 532 nm and 1064 nm backscatter calibra- 
tion coefficients output in x minute segments. Depending on options used in the ancillary 
atmosphere constants file, 532 nm and 1064 nm calibration coefficients are calculated for 
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each second of the granule. Options include averaging the segment coefficients or using lab- 
measured coefficients instead, since the calculated coefficients, especially the one at 1064 nm, 
may be unreliable due to low signal at high altitude. 

11 .6.1 .1 .2 ATM LI B Interpolate POD (CJntrpPOD) 

Creates the precision orbit determination (POD) position vector based on time. This is a com- 
mon routine used by several processes. 

11.6.1.1.3 ATM LIB Calculate Profile Locations (C_CalcSpLoc) 

Utilizes the POD position vector to generate the profile location at 1 second. This is a com- 
mon routine used by several processes. It also computes the satellite range to ellipsoid. When 
the precision attitude determination (PAD) and range are input, it calculates the attitude angle 
and topographic elevation. 

11 .6.1 .1 .4 ATM LI B Get Geoid (C_GetGeoid) 

Utilizes the profile location to generate the geoid height at that location. This is a common 
routine used by several processes. The geoid height is used to compute the satellite range to 
geoid. 

11 .6.1 .1 .5 ATM LI B Calculate DEM (E_CalcDEM) 

Utilizes the profile location to generate the Digital Elevation Model (DEM) height at that 
location. This is a common routine used by several processes. 

11.6.1.2 ATM LIB Backscatter Subprocesses 

The ATM LIB Calculate Backscatter Cross Section Profiles process is divided into four sub- 
processes. Following is a description of each subprocess 

11.6.1.2.1 ATM LIB Interpolate Met Data (A_interp_met) 

Interpolates and combines meteorological (met) data and standard atmosphere data to gener- 
ate met profiles at 1 second. Standard atmosphere data are used to augment the met data at 
higher altitudes and are used for the entire output profile if met data are unavailable. 

11 .6.1 .2.2 ATM LI B Calculate Molecular Backscatter Cross Sections 
(A_mbscs) 

Utilizes met profiles at 1 second to create 532 nm and 1064 nm molecular transmission pro- 
files and backscatter cross section profiles at 1 second. 

11 .6.1 .2.3 ATM LI B Vertically Align Profiles (A_rebin_lid) 

Combines and vertically aligns 532 nm and 1064 nm lidar signals to create lidar profiles at 5 
Hz and 40 Hz. For 532 nm, the 5 Hz profiles range from 41 to -1 km below the surface. For 
1064 nm, the 5 Hz profiles range from 20 to -1 km below the surface. In both wavelengths, the 
40 Hz profiles range from 10 to -1 km below the surface. 
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532 M trans 


control 



Figure 11-7 ATM LIB Backscatter Subprocesses 

11.6.1.2.4 ATM LIB Calculate Backscatter Cross Section Profiles (A_ 
bscs) 

Calibrates the 532 nm and 1064 nm lidar profiles by the backscatter calibration coefficients to 
create the attenuated backscatter cross section profiles at 5 Hz and 40 Hz. If the 532 nm back- 
scatter signal is saturated, it is an option to replace it with the corresponding 1064 nm back- 
scatter value. 

11 .6.1 .3 ATM LI B QA Statistics and WriteATM Subprocesses 

The ATM LIB Create QA Statistics and Write ATM process is divided into two subprocesses. 
Following is a description of each subprocess 

11 .6.1 .3.1 ATM LI B Create QA Statistics (A_qa_G7) 

Creates Level IB QA statistics for the granule and outputs them to the QAP07 QA product 
file. 

11 .6.1 .3.2 ATM LI B Write Atmosphere (WriteAtm) 

Writes Level IB data to the GLA07 data product file. 
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GA lun 


control 


GAP 07 


GLA07 



Figure 11-8 ATM LIB QA Statistics and WriteATM Subprocesses 
11.6.1.4 ATM LIB L2 Buffer 20 Seconds Subprocess 

The ATM L2 Buffer 20 Seconds process is a single process. Following is a description 


GA lun 


control 


GAP 07 


GLA07 



Figure 11-9 ATM LIB QA Statistics and WriteATM Subprocesses 

11 .6.1 .4.1 ATM L2 Buffer 20 seconds (A_buff_data) 

Buffers Level IB data for 20 seconds for input into the Level 2 processing. This is necessary 
because lidar signals need to be collected for 20 seconds for high altitude aerosol detection. 
Twenty seconds of data are buffered irrespective of time gaps between data records. 

11.6.1.5 ATM L2 Calculate Layer Heights Subprocesses 

The ATM L2 Calculate Layer Heights process is divided into three subprocesses. Following is 
a description of each subprocess: 

11.6.1.5.1 ATM L2 Calculate Cloud Layers (A_cld_lays) 

Detects cloud layer heights and ground heights at once per 4 seconds, 1 second, 5 Hz, and 40 
Hz. Up to 10 cloud layers may be detected below 20 km, except at the 40 Hz resolution where 
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532 bscs but 


control 



Figure 11-10 ATM L2: Cloud / Aerosol Layer Heights Subprocesses 

up to 1 layer may be detected under 4 km. Layers may only be detected at the higher resolu- 
tions if they were detected at the lower resolutions. A cloud/aerosol discrimination routine 
discriminates some of the layers detected at once per 4 seconds as elevated aerosol layers. 

11.6.1.5.2 ATM L2 Calculate PBL Layer (A_pbl_lay) 

Detects planetary boundary layer (PBL) heights and ground heights at once per 4 seconds and 
5 Hz. 

11.6.1.5.3 ATM L2 Calculate Elevated Aerosol Layers (A_aer_lays) 

Detects elevated aerosol layer heights. Up to 3 aerosol layers may be detected above 20 km at 
once per 20 seconds, while up to 5 aerosol layers may be detected below 20 km at once per 4 
seconds. It is an option whether to use this algorithm to detect aerosol layers below 20 km or 
to keep the aerosol layers detected by the cloud detection algorithm. 

11.6.1.6 ATM L2 Calculate Optical Properties 

The ATM L2 Calculate Optical Properties process is a single process. Following is a descrip- 
tion:. 

11.6.1.6.1 ATM L2 Calculate Aerosol Optical Properties (A_aer_opt_prop) 

Creates cloud and aerosol backscatter and extinction cross section profiles, and cloud, PBL, 
and aerosol optical depths. Cloud data are created at 1 second while PBL and elevated aero- 
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Figure 11-11 Atmosphere Subsystem: Optical Properties Subprocesses 

sol data are created at once per 4 seconds. Optical depths for up to 10 cloud layers are calcu- 
lated, while up to 8 elevated aerosol optical depths are created. 

11.6.1.7 ATM L2 QA Statistics and WriteATM Subprocesses 

The ATM L2 Create QA Statistics and Write ATM process is divided into two subprocesses. 
Following is a description of each subprocess 

11 .6.1 .7.1 ATM LI B Write Atmosphere (WriteAtm) 

Writes Level 2 data to the GLA08-11 data product files. Data products GLA08-11 are always 
created together. Aerosol layer heights are written to GLA08, cloud layer heights are written 
to GLA09, cloud and aerosol backscatter and extinction profiles are written to GLA10, and 
cloud and aerosol optical depths are written to GLA1 1 . 

11.6.2 Structure Charts 

The following structure charts illustrate the organization of the atmosphere computations soft- 
ware modules. Modules are called top to bottom and from left to right. Input variables point 
downwards to the modules that are receiving them while output variables point upwards from 
the module which created them. Control is not an argument, but indicates which modules are 
only selectively called by the atmosphere manager for partial reprocessing. 
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Figure 11-12 ATM L2 QA Statistics and WriteATM Subprocesses 
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Figure 11-13 ATM Calibration Coefficient / Profile Location / DEM Modules 
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Figure 11-15 ATM LIB QA Statistics / Write ATM Modules 
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Figure 11-16 ATM 20 sec Buffering Module 
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Figure 11-18 ATM Optical Properties Module 
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Figure 11-19 L2 QA Statistics / Write ATM Modules 
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Section 12 

GLAS_Reader 

GLASReader is a utility GSAS PGE. 

12.1 Function 

GLAS Reader is a utility GSAS PGE. It reads various GLAS fdes and creates human-read- 
able text output files. 

12.2 Design Approach 

The following design criteria are specific to GLAS_Reader 

• GLAS Reader fully uses the standard routines from the model GSAS PGE. 

• Output files are named by adding extensions to the input file name. 

• GLAS_Reader provides a rudimentary user interface when executed without a control 
file command-line argument. 

12.3 Input and Output Files 

Table 12-1 lists the potential input files to GLAS Reader. All or some of these files may be 
specified. Note, however, than GLAOO APID files may not be specified without also specify- 
ing a corresponding ANC29 file. See the appropriate section of this document or the GLAS 
Data Products Specifications Volumes for details regarding the non-specific files. 


Table 12-1 GLAS_Reader Inputs 


File Spec 

Type 

Source 

Short Description 

anc01*_??.dat 

Dynamic Ancillary 

met_util 

Subsetted meteorological files. 
There is a separate ANC01 file 
per data type. All of the ANC01 
files must be specified. 

anc07*_00.dat 

Static Ancillary 

Science Team 

GLAS error file. 

anc07*_0 1.dat 

Static Ancillary 

Science Team 

GLAS global constants file. 

anc07*_02.dat 

Static Ancillary 

Science Team 

GLAS waveform constants file. 

anc07*_03.dat 

Static Ancillary 

Science Team 

GLAS elevation constants file. 

anc07*_04.dat 

Static Ancillary 

Science Team 

GLAS atmosphere constants 
file. 

anc07*_05.dat 

Static Ancillary 

Science Team 

GLAS LI A constants file. 

anc08*.dat 

Dynamic Ancillary 

U Texas 

Precision orbit file. 

ancl 2*_0 1.dat 

Static Ancillary 

Science Team 

DEM mask file. 
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Table 12-1 GLAS_Reader Inputs (Continued) 


File Spec 

Type 

Source 

Short Description 

anc13*.dat 

Static Ancillary 

Science Team 

Geoid file 

anc16*.dat 

Static Ancillary 

Science Team 

Ocean Tide file 

anc17*.dat 

Static Ancillary 

Science Team 

Load Tide file 

anc18*.dat 

Static Ancillary 

Science Team 

Standard Atmosphere file 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion file. 

anc27*.dat 

Static Ancillary 

Science Team 

Regional mask files. 

anc30*.dat 

Static Ancillary 

Science Team 

Aerosol file 

anc31*.dat 

Static Ancillary 

Science Team 

Troposphere file 

anc32*.dat 

Dynamic Ancillary 

GLAS_L0proc 

Frequency board to GPS time 
correlation file. 

anc33*.dat 

Dynamic Ancillary 

Science Team 

UTC time conversion file. 

anc36*.dat 

Dynamic Ancillary 

atm_anc 

Atmosphere Calibration file. 

anc45*.dat 

Static Ancillary 

Science Team 

Metadata input files. 

Control File 

Control 

ISIPS Operations 

Control file. 

gla00*.dat/ 

ANC29*.dat 

Level-0 APID/ 
Dynamic Ancillary 

EDOS/ 

GLAS_L0proc 

GLAS Level-0 APID files and 
the requisite ANC29 index file. 

gla*.dat 

GLAS Product 

GSAS 

GLAS Product files. 

Gla*.qap 

GLAS Product QA 

GSAS 

GLAS Product Quality Assur- 
ance file. 


GLASReader will create an output file for each type of input file requested. GLASReader 
will add a ‘.txf extension to the name of the file which is processed. Time selection for the 
output files is based on the time specified with the input files or the user interface. 

A corresponding ANC29 file is required to process GLAOO APID files. When processing 
GLAOO APID files, GLAS Reader writes all output to the ANC29 text file, instead of to indi- 
vidual APID files. The benefit of this is that the output is created in time-aligned fashion. Also 
note that specific APID files may be processed even though the ANC29 file was created with 
a superset of the selected APIDs. 

12.4 GLAS_Reader 

The basic processing algorithm is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 
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• Open the specified files (OpenFiles) 

• Print the control file (PrintCntl) 

• Read ancillary files (ReadAnc) 

• Write version info (Write LibVer) 

• Print ancillary files (PrintAnc) 

• Print quality Assurance Files (PrintQAP) 

• Until all input files are processed... 

Read and write data until all data written (ReadData, PrintData) 

• Close all files and generate summaries (Main Wrap) 

PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• Cntl_Init 

• GetControl 

• OpenFiles 

• PrintCntl 

• ReadAnc 

• Write_LibVer 

• Write_eCntl 

• PrintAnc 

• PrintQAP 

• ReadData 

• PrintData 

• MainWrap 
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Section 13 


met util 


13.1 Overview 

metutil is a GSAS utility which uses the minimum functionality of the GSAS core PGE 
model, met util is simply a processing shell wrapped around wgrib legacy code. 

13.2 Function 

Met util reads a WGRIB meteorological (MET) file and creates subset files (i.e. temperature, 
relative humidity, etc.). 

13.3 Design Approach 

• met_util sets up input/output files and uses a system call to execute the wgrib external 
program. 

• met util does not fully follow the model GSAS PGE. 

• met_util does not perform multi-granule processing or allow for time selection. 

• Implementation of the control files does not follow GSAS PGE conventions. 

• No log/metadata (ANC06) file is created. 

13.4 Input and Output Files 

Table 13-1 lists the required inputs to met_util. Table 13-2 lists the outputs created by 
met_util. See the GLAS Data Products Specifications Volumes or GLAS Science Data Man- 
agement Plan for details regarding the these files.. 


Table 13-1 met_util Inputs 


File Spec 

Type 

Source 

Short Description 

anc40*.dat 

Dynamic Ancillary 

GSFC DAAC 

Input NCEP Global Analysis 
met file. 1 by 1 degree gridded 
data set with sampling every 6 
hours. Variables included are 
temperature, geopotential 
height, and relative humidity at 
standard upper atmospheric 
pressure levels. The MET files 
are in the GRIB format, which is 
the WMO (World Meteorological 
Organization) standard for 
exchanging gridded binary data. 
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Table 13-1 met_util Inputs 


File Spec 

Type 

Source 

Short Description 

anc07*_06.dat 

Static Ancillary 

Science Team 

Utility error/constants file. 

Control File 

Control 

ISIPS Operations 

Control file. 


Table 13-2 met_util Outputs 


File Spec 

Type 

Destination 

Short Description 

anc01MD0.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological header file. Sub- 
setted NCEP Global Analysis 
file. 

anc0r_01.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological precipitable 
water file. Subsetted NCEP 
Global Analysis file. 

anc01MD2.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological height file. Sub- 
setted NCEP Global Analysis 
file. 

anc01MD3.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological relative humidity 
file. Subsetted NCEP Global 
Analysis file. 

anc01*_04.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological temperature file. 
Subsetted NCEP Global Analy- 
sis file. 

anc01MD5.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological wind speed u 
file. Subsetted NCEP Global 
Analysis file. 

anc01MD6.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological wind speed v 
file. Subsetted NCEP Global 
Analysis file. 

anc01*_07.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological PBL height file. 
Subsetted NCEP Global Analy- 
sis file. 

anc01MD8.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological specific humid- 
ity file. Subsetted NCEP Global 
Analysis file. 

anc01MD9.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological above ground 
temperature file. Subsetted 
NCEP Global Analysis file. 

anc0r_10.dat 

Dynamic Ancillary 

atm_anc 
GLAS Atm 
GLAS_Alt (elev) 

Meteorological total cloud cover 
file. Subsetted NCEP Global 
Analysis file. 
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13.5 Functions 

met_util includes the following functions: 

• - M_read_control_mod.f90: Reads the control file and passes the input and output file 
names to the program. 

• - wgrib: A stand alone 'C' program developed at NCEP to manipulate and decode 
GRIB files. This routine is used extensively to extract relevant MET parameters and 
create global data files. See http://wesley.wwb.noaa.gov/wgrib.html for details on 
wgrib. 

13.6 Functional Overview 



Figure 13-1 Process Flow Diagram: Overall Process 

The driver calls the routine that reads the control file and passes back the input and output file 
names. These names are passed to a script which calls an executable (wgrib) that creates the 
subset files 
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Shell Script 


Figure 13-2 



Process Flow Diagram: Shell Script 
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Section 14 

reforbit util 


14.1 Overview 

reforbitutil is a GSAS utility. It does not follow the GSAS core PGE model. 

14.2 Function 

The purpose of the reforbit util program is to process a given Reference Orbit file for all 
ascending equatorial crossings. Each ascending equatorial crossing will be given a track 
number. The first track west of Greenwich (or on Greenwich) will be assigned a Track num- 
ber of 1 and its time will be determined. All consecutive tracks after that (in increasing time 
order) will be assigned numbers 2, 3, 4, and so on. All tracks that were to the right of Track 
1, will be wrapped around the last track on the left and numbered accordingly. 

14.3 Design Approach 

• reforbit util does not follow the model GSAS PGE. 

• reforbit util does use facilities of the common libraries. 

• reforbit util does not perform multi-granule processing or allow for time selection. 

• Implementation of the control files does not follow GSAS PGE conventions. 

• No log/metadata (ANC06) file is created. 

14.4 Input and Output Files 

Table 14-1 lists the required inputs to reforbit_util. Table 14-2 lists the outputs created by 
reforbit util. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files.. 


Table 14-1 createGran_util Inputs 


File Spec 

Type 

Source 

Short Description 

anc26*.dat 

Dynamic Ancillary 

UTexas 

Reference orbit t file. 

anc07*_06.dat 

Static Ancillary 

Science Team 

Utility error/constants file. 

Control File 

Control 

ISIPS Operations 

Control file. 


14.5 Functions 

reforbit util includes the following functions: 

• rd_reforb_cntrl_mod.f90: Reads the control file and passes the input and output file 
names to the program. 
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Table 14-2 createGran_util Outputs 


File Spec 

Type 

Destination 

Short Description 

anc22*.dat 

Dynamic Ancillary 

l-SIPS 

Track file.The first record con- 
tains the average period of the 
tracks (in seconds), and the 
number of tracks in the refer- 
ence orbit file. All subsequent 
records contain the longitude (in 
degrees E longitude), the track 
number, time in seconds relative 
to Track 1 , the actual MJD time 
(in days), and the seconds of 
day. 

anc43*.dat 

Dynamic Ancillary 

SCF 

SCF track file. 

anc28*.dat 

Dynamic Ancillary 

ISIPS 

NOSE track file 


• c_profRefOrbit_mod.f90: Reads the Reference Orbit file and determines the ascend- 
ing equatorial crossing longitudes and track numbers. 

• c_legacyintrpPOD_mod.f90: Interpolates the reference orbit data to determine the 
position vectors for a given time. 

• c_calcsploc_mod.f90: Calculates the location (lat, Ion) that corresponds to a given 
position vector. 

14.6 Functional Overview 

The driver calls the routine that reads the control file and passes back the input and output file 
names. It then opens these files and passes their Ion numbers to c_procRefOrbit. The 
c_procRefOrbit routine will read the reference orbit file one record at a time and geolocate 
using c_calcsploc. It will be looking for records that straddle the equator in the ascending 
direction. When such records are found, the exact equatorial crossing location and time is 
determined. This is done by determining the location at a time that is midway between the 
two records that straddle the equator. If the latitude is within tolerance limits, an ascending 
equatorial crossing has been found. If not, the location of the midpoint between the recently 
located point and one of the previous points on the other side of the equator is determined, and 
checked if it is on the equator. This process is repeated until the exact equator crossing is 
determined (within tolerance limits). 

The c_procRefOrbit routine will then assign a track number to this equator crossing, and will 
continue the above process until all records are read or until it starts reading repeat tracks. 
The routine will then search through all the equator crossing longitudes to find the first cross- 
ing west of (or on) Greenwich. That track will be assigned a Track number of 1 and its time 
will be determined. All consecutive tracks after that (in increasing time order) will be 
assigned numbers 2, 3, 4, and so on. All tracks that were to the right of Track 1, will be 
wrapped around the last track on the left and numbered accordingly. 
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Figure 14-1 Process Flow Diagram 
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Section 15 

createGran util 


15.1 Overview 

createGran_util is a GSAS utility. It does not use the functionality of the GSAS core PGE 
model. 

15.2 Function 

The purpose of the createGran util program is to process a given Predicted Orbit file for all 
ascending equatorial crossings, and +/- 50 degree latitude crossings. The +/-50 degree lati- 
tude crossings will be designated by segment numbers. The segment numbers are defined as 
follows: 

• Segment 1 - start of +50 degree latitude crossing (on the ascending portion of the 
track), 

• Segment 2 - start of +50 degree latitude crossing (on the descending portion of the 
track), 

• Segment 3 - start of a -50 degree latitude crossing (on the descending portion of the 
track), 

• Segment 4 - start of a -50 degree latitude crossing (on the ascending portion of the 
track). 

15.3 Design Approach 

• createGran_util does not follow the model GSAS PGE. 

• createGran_util does use facilities of the common libraries. 

• createGran util does not perform multi-granule processing or allow for time selection. 

• Implementation of the control files does not follow GSAS PGE conventions. 

• No log/metadata (ANC06) file is created. 

15.3.1 Definitions 

The reference orbit information will be stored in the Oracle database, and will henceforth be 
referred to as the Reference Orbit table. The Reference Orbit table will contain the following 
information for each of the Reference Orbits to be used during data processing: 

1) The Repeat groundtrack phase (p): 

where, 

P=1 for 8 -day 
P=2 for 183 -day 
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P=3 for transfer orbit 

2) Reference Orbit number (r): 

This number will start at 1 , and increment each time we receive a new reference orbit. It 
will be unique for each set of ground tracks. 

3) Instance (k): 

The instance will start at 1 , and increment by one every time we change from one refer- 
ence orbit to another. 

4) Cycle (ccc): 

The cycle number will restart at 1 every time the instance number, k, changes. The cycle 
number will then increment within the instance every time track 1 for that orbit is reached. 

It should be noted that most instances will begin in an arbitrary track (not 1) because of 
how we are numbering the tracks. 

5) Track (tttt): 

Tracks are defined from a reference orbit. Each track begins and ends at the ascending 
equator crossing. Tracks will be numbered such that track 1 is the closest track to Green- 
wich from the west, and then contiguous in time after that. For transfer orbits, for which 
we have no predefined reference orbit, track 1 is the first track for which we have data for 
that instance, k. 

6) Begin Time: 

Begin time to use the reference orbit file. 

7) End Time: 

End time to use the reference orbit file. 

8) Begin Track Number: 

The first track number that is before the Begin time. 

9) Time into Begin Track: 

Time into the begin track. This will be difference between the Begin Time of the refer- 
ence orbit file and the beginning time of the Begin Track. 

10) Number of tracks per cycle: 

The number of tracks per cycle for the reference orbit. 

11) Begin Rev number: 

TBD 

12) Track file name: 

The Track file name will be the name of the track file that corresponds to the reference 
orbit file. This file will contain all the tracks that are relevant to the reference orbit file, 
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along with their ascending node longitudes. These tracks will be numbered according to 
the convention mentioned above in 5. 

15.3.2 Assumptions 

1) A start and end time will be provided by UTCSR for each reference orbit. The start 
time will be provided before we get data or a predicted orbit file for that reference orbit. 
The end time will be provided at a later date. 

2) The reference orbit file will be cataloged in the reference orbit ID table after the refer- 
ence orbit tracks are created. The name of the reference orbit track file will be noted in 
this table. 

3) For transfer orbits we will not receive real reference orbits from UTSCR, and will need 
to use the tracks generated from the predicted orbit file. This will be done by running the 
reference orbit track program on the predicted orbit file. 

4) Each predicted orbit file will be for 48 hours, starting at noon on day n-1, and going 
until noon on day n+1 , where n is the day for which we want to use the file. A day starts 
at 00 hours, and ends at midnight. 

5) When a predicted orbit file is received, the reference orbit files pertaining to this pre- 
dicted orbit file should already be in the reference orbit ID table. 

6) For GLA01, 05, and 06, each granule starts at the beginning of each segment (for all 
tracks). 

7) For GLA02, and GLA07, each granule starts at segment 1 of odd track numbers. 

8) For GLA08 through GLA15, each granule starts at segment 1, when the track number 
MODed by 14 equals 1. 

9) The start of each new instance, or the start of a new cycle, will automatically create a 
new granule. 

10) During normal processing, the granule files will start with the first granule encoun- 
tered in the predicted orbit file. When there is a new instance, then the first granule will 
be the granule preceding the first encountered granule. Its start time will be the actual 
start time of the data. The next granule will be the first encountered granule, with its start 
time. All subsequent granules will be numbered and processed as in the normal case. 

1 1) A predicted orbit file can cover more than one reference orbit. 

12) The SCF rev file will always start with rev number 1, and increment for every rev. 

13) The cycle in a transfer orbit will span only one track (as opposed to 1 19 tracks in an 8- 
day orbit file). 

15.4 Input and Output Files 

Table 15-1 lists the required inputs to createGranutil. Table 15-2 lists the outputs created by 
createGran_util. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files.. 
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Table 15-1 createGran_util Inputs 


File Spec 

Type 

Source 

Short Description 

anc26*.dat 

Dynamic Ancillary 

UTexas 

Predicted orbit file 

anc42*.dat 

Dynamic Ancillary 

ISIPS 

Reference orbit table 

anc07*_0 1.dat 

Static Ancillary 

Science Team 

Global constants file 

anc07*_06.dat 

Static Ancillary 

Science Team 

Utility error/constants file 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion 

Control File 

Control 

ISIPS Operations 

Control File 


Table 15-2 createGran_util Outputs 


File Spec 

Type 

Destination 

Short Description 

-none- 

Dynamic Ancillary 

l-SIPS 

Quarter rev file. Contains the 
quarter rev start time (in J2000 
seconds), repeat ground track 
phase, reference orbit number, 
instance, product type (1 for 
quarter rev granule), cycle num- 
ber, track number, and segment 
number for all the quarter rev 
granules determined from the 
predicted orbit file. 

-none- 

Dynamic Ancillary 

l-SIPS 

Two rev file. Contains the two 
rev start time (in J2000 sec- 
onds), repeat ground track 
phase, reference orbit number, 
instance, product type (2 for two 
rev granule), cycle number, 
track number, and segment 
number for all the two rev gran- 
ules determined from the pre- 
dicted orbit file.. 


Version 6.0 


Page 15-4 


March 2013 








createGran util 


The GLAS Science Algorithm Software Detailed Design Document 


Table 15-2 createGran_util Outputs (Continued) 


File Spec 

Type 

Destination 

Short Description 

-none- 

Dynamic Ancillary 

l-SIPS 

Fourteen rev file. Contains the 
fourteen rev start time (in J2000 
seconds), repeat ground track 
phase, reference orbit number, 
instance, product type (3 for two 
rev granule), cycle number, 
track number, and segment 
number for all the fourteen rev 
granules determined from the 
predicted orbit file. 

-none- 

Dynamic Ancillary 

l-SIPS 

SCF rev file. Contains the rela- 
tive rev numbers, starting from 1 
(during each execution), that 
were determined from the given 
predicted orbit file. 


15.5 Functions 

createGran_util includes the following functions: 

• rd_GranCntrl_mod.f90: Reads the control file and passes the input and output file 
names to the program. 

• createGranule_mod.f90: Reads the Predicted Orbit file and determines the ascending 
equatorial crossing longitudes and times, as well as the granule start times and loca- 
tions (latitudes and longitudes). The results are output to the two files indicated in the 
control file. 

• c_legacyintrpPOD_mod.f90: Interpolates the predicted orbit data to determine the 
position vectors for a given time. 

• c_calcsploc_mod.f90: Calculates the location (lat, Ion) that corresponds to a given 
position vector. 

15.6 Functional Overview 

The driver calls the routine that reads the control file and passes back the input and output file 
names. It will then open two scratch files (a rev file, and a granule file). The LUN numbers of 
these files, along with the predicted orbit file, will be passed to the createGranule routine. 

This routine will read the predicted orbit file, and calculate the ascending equatorial crossing 
locations and times (which will be written to the rev file), and the segment locations and times 
(which will be written to the granule file). Once the rev and granule files have been popu- 
lated, the utility will check to see what the processing mode has been set to. If it is set to 
REFORB, then the update_RefTab routine will be called. This routine will read the reference 
orbit ID file, and check to see which of the reference orbits do not have a begin track. It will 
then check if that reference orbit is a candidate for update. This will be determined by the ref- 
erence orbit begin time and the predicted orbit start and stop time. The routine will then 
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determine the closest rev to the reference orbit begin time or the predicted orbit start time 
(which ever is greater). The track number corresponding to the closest rev will be determined 
from the reference orbit track file. The begin track number will then be determined, as well 
as the time into the begin track. If it is a transfer orbit, then the begin track will be set to 1, 
and the period will be set to the period of the rev file. 



Figure 15-1 Process Flow Diagram 
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If the processing mode is set to PREDORB, then the calc granules routine will be called. The 
predicted orbit fde will be read, and processing will start from the predicted orbit start time or 
the reference orbit begin time (which ever is greater). The processing will continue until the 
reference orbit end time (if it is greater that zero), or the predicted orbit end time (which ever 
is less). The cycle number will be determined at the beginning on the basis of the granule 
start time and the reference orbit start time. The start track number will also be determined. 
All subsequent tracks will be increments of the start track. The 1/4 rev, 2 rev, and 14 rev 
granules will be written out to appropriate 1/4 rev, 2 rev, and 14 rev granule fdes. Using the 
information from the 1/4 rev information file, a SCF rev file will also be created. The first 
rev on that file will be rev 1 , and its start time will be the start of the actual rev that the 1/4 rev 
information file started with. All subsequent revs will be increments of rev 1 , and will ignore 
any change of reference orbit files during the run. 
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Section 16 


atm anc 


16.1 Overview 

atm_anc is a GSAS utility. It does not use the functionality of the GSAS core PGE model. 

16.2 Function 

Atmanc reads a GLA02 product file and computes 532 nm and 1064 nm calibration coeffi- 
cients for specified-time segments. The coefficients per segment are output to an ancillary 
(ANC36) file which is used in the level IB atmosphere data processing. A second ancillary 
file (ANC44) contains the 532 and 1064 data for clouds that were detected above about 10 
km. 

16.3 Design Approach 

• atm_anc does not follow the model GSAS PGE. 

• atm anc does use facilities of the common libraries. 

• atm_anc does not perform multi-granule processing or allow for time selection. 

• Implementation of the control files does not follow GSAS PGE conventions. 

• No log/metadata (ANC06) file is created. 

16.4 Input and Output Files 

Table 16-1 lists the required inputs to atm anc. Table 16-2 lists the outputs created by 
atm_anc. See the GLAS Data Products Specifications Volumes or GLAS Science Data Man- 
agement Plan for details regarding the these files.. 


Table 16-1 atm_anc Inputs 


File Spec 

Type 

Source 

Short Description 

gla02*.dat 

LI A Product 

GLAS_L1A 

GLAS LI A Atmosphere product 
file. 

anc01*_??.dat 

Dynamic Ancillary 

met_util 

Subsetted MET files. There is a 
separate MET file per MET data 
type. All of the MET files (1-10) 
must be specified. 

anc07*_00.dat 

Static Ancillary 

Science Team 

GLAS error file. 

anc07*_02.dat 

Static Ancillary 

Science Team 

GLAS atmosphere constants 
file. 

anc18*.dat 

Static Ancillary 

Science Team 

Standard Atmosphere file 
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Table 16-1 atm_anc Inputs (Continued) 


File Spec 

Type 

Source 

Short Description 

anc35*.dat 

Static Ancillary 

Science Team 

Ozone file 

Control File 

Control 

ISIPS Operations 

Control file. 


Table 16-2 atm_anc Outputs 


File Spec 

Type 

Destination 

Short Description 

anc36*.dat 

Dynamic Ancillary 

atm_util 

Atmosphere Calibration file. 

anc44*.dat 

Dynamic Ancillary 

Science Team 

Atm 1064 Cirrus CAL File 


16.5 Functions 

atm_anc includes the following functions: 

• A_common_mod.f90: Contains common parameters and structures 

• A_read_control_mod.f90: Reads the control file and passes back the input and output 
file names to the program 

• A_prod_reader_mod.f90: Opens and reads the product file 

• A_open_met_mod.f90: Opens and reads the MET and standard atmosphere files 

• A_open_ozone_mod.f90: Opens and reads the ozone file 

• A_sum_lidar_mod.f90: Sums and averages lidar data over time segments 

• A_seg_cal_cofs_mod.f90: Creates 532 nm and 1064 nm calibration coefficients for 
each time segment and writes results to an output file 

16.6 Functional Overview of Calibration Modules 

This portion is taken from the document, "Calibration Processing ATBD v4.1.doc" written 
January, 2001 by Steve Palm of the GLAS lidar science team. The atmosphere ancillary utility 
was written to perform the algorithms described in this document. The A_sum_lidar_mod.f90 
subroutine performs the functions of the SAM module described below and the 
A_seg_cal_cofs_mod.f90 subroutine performs the functions of the CALM module. 

16.6.1 Segment Averaging Module (SAM) 

The segment averaging reads in the output from GLA02 and produces segment averages of 
the data at two calibration heights. There is an upper calibration height and a lower calibration 
height. The upper calibration height is fixed (or at least specified by input from the constants 
file), while the lower calibration height is calculated from the minimum average signal 
between 8 and 1 5 km. SAM also eliminates profiles that are cloud contaminated from the seg- 
ment average (this only applies to the lower calibration height). The steps (directly from the 
ATBD) are given below: 
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R e ad C ontro I F ile ( A_ read_ COfttrof ) 
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Figure 16-1 Process Flow Diagram 
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1) Construct a 1 Hz continuous profile of P’ from -1 to 41 km for the 532 channel and 
from -1 to 20 km for the 1064 channel. 

2) Add the background to ‘summing’ variables for each channel 

3) Sum the P’ 532 data from HI to H2 km and add it to a ‘summing’ variable. The val- 
ues of HI and H2 will be roughly 29 and 31, respectively, but will be changeable 
and read in from the constants file. Increment an ‘upper counter’. 

4) Check for clouds from 22 km to 8 km above ground. If clouds were not found for 
this second, then do the following (number 5 below): 

5) Add the 1 Hz data (each bin) between 8 and 15 km to a ‘summing’ array for each 
channel. Increment a Tower counter’. 

6) If you have been doing this for t minutes, where t is read in from the constants file 
(default value: t=10), and at least 50 percent of the expected number of seconds 
have been summed (based on the ‘upper counter’), then do the following: 

compute the average 532 signal from HI to H2 km for the entire ‘f minute 
segment. Call this P2(532) from the sum generated in step 3 above. 

If the Tower counter’ exceeds 50 percent of the expected number of seconds, 
then perform c, d, and e below. Otherwise, set PI (532) and PI (1064) to invalid 
and skip c, d and e. This effectively means that clouds have made calculations 
impossible at the lower height. 

Compute the average 532 and 1064 profiles between 15 and 8 km from the 
summing array produced in steps 4 and 5 above. 

Find the height of the minimum in the 532 average profile between 8 and 15 
km call this hmin - this is the lower calibration height 

Compute the average of the data between hmin+D and hmin-D km for both the 
532 and 1064 channels, where D is in km and is read from the constants file 
(default = 1km). Call these PI (532) and PI (1064). 

Compute the average background for the segment for each channel call these 
B532 and B 1064 

Output to a structure: Pl(532), Pl(1064), P2(532), B532, B1064, hmin, D, HI, 
H2 and: the latitude, longitude and time at ‘m’ points along the segment, where 
m is a variable read from the constants file, not to exceed 30. A default value 
for m is 20. These points would be t/m minutes apart. 

7) 1. If after ‘f minutes, less than 50 percent of the expected number of seconds have 
been summed (based on the ‘upper counter’), then output missing values (invalid) 
for Pl(532), Pl(1064), P2(532), B532, B1064, and the other output described in 6g 
above. 

8) Zero out summing variables, summing array and counters 

9) Process next ‘f minute segment in the same manner 
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16.6.2 CALibration Module (CALM) 

The function of CALM is to compute the calibration constant for each of the segments output 
by SAM. The following steps summarize the process: 

1) Read in the output from the segment averaging utility (run after GLA02 com- 
pletes). This output contains segment averages (maybe 20-30 per granule) at the 
two calibration heights. For each segment average, there is maybe 10-20 latitude/ 
longitude pairs (these are the m points along the orbit segment, described in 6g 
above). NOTE: If the SAM and CALM modules are combined into one module, 
obviously this step is skipped. 

2) For each segment that has a valid (not invalid) Pl(532), Pl(1064) or P2(532) do 
steps 3-6 below. If all 3 of these are invalid, then there is no need to perform steps 
3-6, below. In this case, we set the 3 calibration values to invalid and skip to step 9 
below) 

3) At each lat/lon point, compute the average attenuated molecular backscatter at the 
two calibration heights using ATBD equations 3.2.5 and 3.2.11 (here average 
means a vertical average - nominally 2 km). This requires access to the MET data 
at that lat/lon. 

4) At each lat/lon point, compute the ozone transmission from the top of the atmo- 
sphere to the calibration height (ATBD, equation 3.2.8). 

5) Compute the average attenuated molecular backscatter for the segment at the two 
calibration heights and the average ozone transmission for the segment (average of 
the values calculated in steps 3 and 4). 

6) Compute the calibration constant as the ratio of the segment signal average to the 
average attenuated molecular backscatter times the average ozone transmission 
(ATBD, equation 3.2.6). 

7) Repeat steps 2-6 for each of the 20-30 segment averages. This will yield 20-30 of 
the following: Cl(532) - the lower 532 calibration constant, Cl(1064) - the 1064 
calibration constant and C2(532) - the upper 532 calibration constant. 

8) For each segment, write out to a file the following: 1) The start and end time for the 
segment, 2) the 3 calibration values (532 upper and lower, and 1064 lower), 3) the 
standard deviations of the C values (s 1(532), sl(1064) and s2(532)), 4) the three 
segment signal averages (532 upper and lower, 1064 lower), 5) the segment average 
attenuated molecular backscatter at the two calibration heights, 6) the segment 
average ozone transmission from the top of the atmosphere to the calibration 
height, 7) the center height and thickness of the upper calibration zone, 8) the center 
height and thickness of the lower calibration zone, 9) the segment average 532 
background (B532). Note that if calibration points are thrown out during step 8 
above, they are still output to the file, but have the value of ‘invalid’. 
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Section 17 

GLAS Meta 


17.1 Function 

GLAS Meta is a utility GSAS PGE. It will read product header records and the ANC45 meta- 
data input files to create inventory-level EOS metadata files. 

17.2 Design Approach 

The following design criteria are specific to GLAS_Meta 

• With the exception of ReadData, GLASMeta fully uses the standard routines from 
the model GSAS PGE. 

• Only the header information is read from the product files. 

17.3 Input and Output Files 

Table 17-1 lists the required inputs to GLASMeta. Table 17-2 lists the outputs created by 
GLASMeta. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files.. 


Table 17-1 GLAS_Meta Inputs 


File Spec 

Type 

Source 

Short Description 

gla*.dat 

GLAS Products 

GSAS 

GLAS product files. 

anc45*.dat 

Static Ancillary 

Science Team 

Product metadata input files. 

anc04*.dat 

Dynamic Ancillary 

UTexas 

IERS Polar Motion and Earth 
Rotation Data File. 

anc46*_0004.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC09. 

anc08*.dat 

Dynamic Ancillary 

UTexas 

Precision Orbit file. 

anc46*_0008.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC08. 

anc09*.dat 

Dynamic Ancillary 

UTexas 

Precision Attitude file. 

anc46*_0009.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC09. 

anc20*.dat 

Dynamic Ancillary 

UTexas 

Predicted orbit file. 

anc46*_0020.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC20. 

anc22*.dat 

Dynamic Ancillary 

ISIPS 

Track file. 
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Table 17-1 GLAS_Meta Inputs (Continued) 


File Spec 

Type 

Source 

Short Description 

anc46*_0022.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC22. 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion file. 

anc46*_0025.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC25. 

anc33*.dat 

Dynamic Ancillary 

Science Team 

UTC time conversion file. 

anc46*_0033.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC33. 

anc37*.dat 

Dynamic Ancillary 

UTEXAS 

Spacecraft CG file. 

anc46*_0037.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC37. 

anc39*.dat 

Dynamic Ancillary 

UTEXAS 

GPS file. 

anc46*_0039.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC39. 

anc51*.dat 

Static Ancillary 

GSAS Operations 

SRTM Track files. 

anc46*_0051 .dat 

Static Ancillary 

GSAS Operations 

Ancillary metadata input file for 
ANC51 

anc52*.dat 

Static Ancillary 

Science Team 

Saturation Correction Tables 

anc46*_0052.dat 

Static Ancillary 

Science Team 

Ancillary metadata input file for 
ANC52 

anc07*_0001.dat 

Static Ancillary 

Science Team 

GLAS global constants file. 

Control File 

Control 

ISIPS Operations 

Control file. 


Table 17-2 GLAS_Meta Outputs 


File Spec 

Type 

Destination 

Short Description 

gla*.met 

Metadata 

ECS 

ECS-compliant metadata inven- 
tory files. 

anc04*.met 

Metadata 

ECS 

IERS Polar Motion and Earth 
Rotation metadata File. 

anc08*.met 

Metadata 

ECS 

Precision Orbit metadata file. 

anc09*.met 

Metadata 

ECS 

Precision Attitude metadata file. 

anc20*.met 

Metadata 

ECS 

Predicted orbit metadata file. 

anc22*.met 

Metadata 

ECS 

Track metadata file. 
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Table 17-2 GLAS_Meta Outputs (Continued) 


File Spec 

Type 

Destination 

Short Description 

anc25*.met 

Metadata 

ECS 

GPS/UTC conversion metadata 
file. 

anc33*.mett 

Metadata 

ECS 

UTC time conversion metadata 
file. 

anc37*.met 

Metadata 

ECS 

Spacecraft CG metadata file. 

anc39*.met 

Metadata 

ECS 

GPS metadata file. 

Anc51*.met 

Metadata 

ECS 

SRTM metadata file. 

Anc52*.met 

Metadata 

ECS 

Range saturation metadata file. 

anc06*.txt 

Dynamic Ancillary 

ISIPS Operations 

Standard metadata/processing 
log file. 


17.4 GLAS_Meta 

The basic processing algorithm for GLAS_Meta is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (PrintCntl) 

• Read ancillary files (ReadAnc) 

• Write version info (Write_LibVer, Write_AncVer) 

• Loop through available Product and Ancillary Types... 

- Parse header and control data using appropriate ANC45/46 information to create 
inventory-level metadata. 

• Close all files and generate summaries (Main Wrap) 

17.4.1 PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• Write LibYer 


March 2013 


Page 17-3 


Version 6.0 






The GLAS Science Algorithm Software Detailed Design Document 


GLAS Meta 


• ReadANC 

• Write_AncVer 

• MainWrap 

17.4.2 Metadata Processing 

The process of creating metadata files first begins with the GSAS library routines. Based on 
input file availability, the readGLAxx subroutine reads input product/ancillary header records 
and control information and parses the data into common and local header data structures. The 
common header data structure is further subsetted into a metadata substructure by matching 
header keywords with keywords found in the appropriate ANC45/46 file. The header is parsed 
in a very specific way. It is important to note that the first keyword found which does not 
match a keyword in the ANC45/46 files causes the rest of the header information to be stored 
in the commonheader data structure (NOT in the metadata substructure). It is critical that the 
metadata information within the product headers be contiguous and consistent with the 
ANC45/ANC46 files. Inconsistency will prevent the metadata information from being filled 
correctly. 

After the header information is parsed, WriteMetaFile walks through the ANC45/ANC46 key- 
words and finds appropriate values from the header metadata substructure. It then replaces 
default values found in the ANC45/ANC46 file with actual values contained within the prod- 
uct headers. It writes the keywords and values in a format specific to EOS inventory-level 
metadata. 

17.4.3 ANC45/ANC46 File Updates 

The manually created ANC45/ANC46 text files share information contained in the ECS 
descriptor files. The descriptor files are created in cooperation with ECS. There is a descrip- 
tor for each product and selected ancillary files. The descriptor files contain a section of com- 
ments on implemented changes, followed by collection and core (inventory) metadata 
information in ODL (Object Description Language) format. Changes made to the ECS 
descriptor files will produce a new MCF file and will be delivered to the developer from ECS 
when requested. MCF files contain strictly inventory/core metadata, and product specific 
attribute information. MCF files are in Object Description Language format. 

The first section of the ANC45 file contains global metadata parameters, and remains the 
same for all products. The second section contains additional attributes. The last section con- 
tains the parameters/GCMD keywords that are specific to a particular product, and can be 
traced back to the collection level for a particular product. When a new MCF file is created by 
ECS it may have changes that will require the ANC45/ANC46 file to be changed. Addition or 
removal of additional attributes, or changes in the parameters are possible changes that would 
require an ANC45 change. Changes to the parameters or additional attributes must be coordi- 
nated with ECS, then the ANC45 can be edited by hand to make the changes. The format of 
the ANC45 file must not be altered outside of additional attribute or parameter container 
changes. The EOSDIS ICD Between ECS and SIPS Volume 0 Interface Mechanisms 423-41- 
57 explains the exchange of MCF files, and .met files between EOSDIS and I-SIPS. 
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The ANC46 file contains only the global metadata parameters section. Product specific attri- 
butes, and parameters have not been defined for the selected ancillary files that have descrip- 
tors. 

Partial Sample of an ANC45 file 

# 

# Global Metadata Parameters 

# 

ReprocessingPlanned = further update anticipated using enhanced PGE 

ReprocessingActual = processed once 

LocalGranulelD = NOT SET 

ProductionDateTime = NOT SET 

Local VersionID = NO SET 

OrbitNumber = NOT SET 

EquatorCrossingLong = NOT SET 

EquatorCrossingTime = NOT SET 

EquatorCrossingDate = NOT SET 

ShortName = NOT SET 

VersionID = 1 

InputPointer = NOT SET 

RangeBeginningTime = NOT SET 

RangeEndingTime = NOT SET 

RangeBeginningDate = NOT SET 

RangeEndingDate = NOT SET 

PGEVersion = NOT SET 

# 

# Additional Attributes 

# 

Additional_Attribute = Track 
Track = NOT SET 

AdditionalAttribute = TrackSegment 
Track Segment = NOT SET 
AdditionalAttribute = ReferenceOrbit 
ReferenceOrbit = NOT SET 
AdditionalAttribute = Instrument_State 
InstrumentState = NOT SET 
AdditionalAttribute = InstrumentStateDate 
InstrumentStateDate = NOT SET 
AdditionalAttribute = InstrumentStateTime 
InstrumentStateTime = NOT SET 
AdditionalAttribute = Cycle 
Cycle = NOT SET 
AdditionalAttribute = Instance 
Instance = NOT SET 
# 

# Parameters - Waveform 
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# 

ParameterN ame= Waveform 
AutomaticQualityFlag = Passed 

AutoQualFlagExpl = Passed indicates parameter passed for specific automatic test; Failed, 
parameter failed specific automatic test. 

OperationalQualityFlag= Inferred Passed 

OpQualFlagExpl = Passed, parameter passed the specified operational test. Inferred 
Pass, parameter terminated with warnings. Failed parameter terminated with fatal errors. 
ScienceQualityFlag = Inferred Passed 

SciQualFlagExpl = Passed, parameter passed the specified science test. Inferred Pass, parame- 
ter terminated with warnings for specified science test. Failed parameter terminated with fatal 
errors for specified science test. 

QAPercentMissingData = 0 
QAPercentOutofBounds = 0 
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Section 18 

GLAS Tick 


18.1 Function 

GLASTick reads ANC09, ANC32 and (optionally) GLA03 input files and creates 
ANC50 00 and ANC50 01 output files. The ANC50 00 contains merged ANC09/ANC32 
information which is written at a GPS update event. The ANC50 01 contains 6 hour statistics 
for oscillator and engineering data. 

18.2 Design Approach 

The following design criteria are specific to GLAS Tick. 

• GLAS Tick fully uses the standard routines from the model GSAS PGE. 

• GLA03 processing is optional. GLAS Tick performs GLA03 processing based on the 
presence of a GLA03 input file 

• There are no execution scenarios for GLAS Tick (besides that determined by the pres- 
ence or absence of GLA03 inputs). 

18.3 Input and Output Files 

Table 18-1 lists the required inputs to GLAS Tick. Table 18-2 lists the outputs created by 
GLAS Meta. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files.. 


Table 18-1 GLAS_Tick Inputs 


File Spec 

Type 

Source 

Short Description 

anc07*_00.dat 

Static Ancillary 

Science Team 

Error file. 

anc07*_0 1.dat 

Static Ancillary 

Science Team 

Global constants file. 

anc07*_05.dat 

Static Ancillary 

Science Team 

L1A constants file. 

anc09*.dat 

Dynamic Ancillary 

UTexas 

Precision Attitude file. 

anc25*.dat 

Dynamic Ancillary 

Science Team 

GPS/UTC conversion file. 

anc32*.dat 

Dynamic Ancillary 

GLAS_L0proc 

GPS time correlation file. 

anc33*.dat 

Dynamic Ancillary 

Science Team 

UTC time conversion file. 

gla03*.dat 

(optional) 

LI A Product 

GLAS_L1A 

L1A Engineering product file. 

Control File 

Control 

ISIPS Operations 

Control file. 
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Table 18-2 GLAS_Tick Outputs 


File Spec 

Type 

Destination 

Short Description 

anc50*_0000.txt 

Text file 

ISF/Science Team 

Merged ANC09/ANC32 file. 

anc50*_0001.txt 

Text file 

ISF/Science Team 

Frequency trend file. 

anc06*.txt 

Dynamic Ancillary 

ISIPS Operations 

Standard metadata/processing 
log file. 


18.4 GLAS_Tick 

The basic processing algorithm for GLAS_Meta is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (PrintCntl) 

• Read ancillary files (ReadAnc) 

• Write version info (WriteLibVer, Write AncVer) 

• Initialize output Headers 

• Initialize Statistics 

• Until all data are processed 

Compute Statistics 

- Write Tick Data upon GPS Time Update 

- Write Engineering Statistics at desired frequency 

• Close all files and generate summaries (Main Wrap) 

18.4.1 PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• WriteLibVer 

• ReadANC 

• Write AncYer 
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• MainWrap 

18.4.2 Engineering Statistics Processing 

Selected statistical Engineering parameters are computed at a 6 hour interval. Statistics 
reported include minimum, maximum, and mean. Precision problems are avoided by using 
offsets to perform computations on the deltas of parameters (as opposed to using the whole 
values). Common routines from the math library (libmath) are used to ensure consistency. 

18.4.3 GPS Update Processing 

GPS update information is written only when a GPS update event occurs (nominally every 10 
seconds.) Please reference the “Construction of the Lookup Table of GLAS Clock Oscillator 
Frequencies” memo by C. Field, X. Sun, and D. Hancock for algorithm specifications. 
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Section 19 

GLAS_APID 

GLASAPID is a utility GSAS PGE. It will read ANC29, ANC32, and/or GLAOO APID files 
and create tab-delimited text output files of the data. Currently, the only APID supported is 
APID19. Future versions of this utility will provide support for APID12 and APID13. 

19.1 Function 

GLAS APID creates tab-delimited text output files for ANC29, ANC32 and APID 19. The 
APID 19 data are split among multiple files, the data being separated by subpacket type. 

19.2 Design Approach 

The following design criteria are specific to GLAS_APID 

• With the exception of ReadData, GLAS_APID fully uses the standard routines from 
the model GSAS PGE. 

• Output files are named by adding extensions to the input file name. 

• Multiple-input files (of differing types) is supported. Multiple-granule input is not sup- 
ported since APID 19 output granules must be multiple-granule. 

• All products are output at one record per 1 sec. Only the first of the 40/second shot 
times is output in APID 19. 

19.3 Input and Output Files 

Table 19-1 lists the required inputs to GLAS APID. Table 19-2 lists the outputs created by 
GLAS APID. See the GLAS Data Products Specifications Volumes or GLAS Science Data 
Management Plan for details regarding the these files. Those files which are only required by 
specific subsystems are noted within the table.. 


Table 19-1 GLAS_APID Inputs 


File Spec 

Type 

Source 

Short Description 

gla00*_1 9.dat 

Level-0 APID19 

EDOS 

GLAS Level-0 APID19files. 

anc07*_00.dat 

Static Ancillary 

Science Team 

GLAS error file. 

anc07*_01.dat 

Static Ancillary 

Science Team 

GLAS global constants file. 

anc29*.dat 

Dynamic Ancillary 

GLAS_L1A 

Index file correlating APID 
times. 

anc32*.dat 

Dynamic Ancillary 

GLAS_L1A 

GPS time correction file used for 
precision timing of GLAS data. 

Control File 

Control 

ISIPS Operations 

Control file. 
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Table 19-2 GLAS_APID Outputs 


File Spec 

Type 

Destination 

Short Description 

gla00*_19.dat.time. 

txt 

Tab-delimited text. 

User 

Time-related APID19 parame- 
ters. 

gla00*_19.dat.ac.tx 

t 

Tab-delimited text. 

User 

Altimeter-digitizer-related 
APID19 parameters. 

gla00*_19.dat.pc.tx 

t 

Tab-delimited text. 

User 

Photon-counter-related APID19 
parameters. 

gla00*_19.dat.cd.tx 

t 

Tab-delimited text. 

User 

Cloud digitizer-related APID19 
parameters. 

gla00*_19.dat.time. 

txt 

Tab-delimited text. 

User 

Time-related APID19 parame- 
ters. 

gla00*_19.dat.gps.t 

xt 

Tab-delimited text. 

User 

GPS-related APID19 parame- 
ters. 

gla00*_1 9.dat.ct.txt 

Tab-delimited text. 

User 

C&T-related APID19 parame- 
ters. 

anc29fdat.txt 

Tab-delimited text. 

Users 

Index file parameters. 

anc32fdat.txt 

Tab-delimited text. 

Users 

GPS time correction parame- 
ters. 

anc06*.dat 

Dynamic Ancillary 

ISIPS Operations 

Standard metadata/processing 
log file. 


19.4 GLAS_APID 

The basic processing algorithm is summarized below: 

• Initialize (Mainlnit) 

• Set the local execution flags (eCntrl_Init) 

• Parse the Control File (GetControl) 

• Open the specified files (OpenFiles) 

• Print the control file (Print Cntl) 

• Read ancillary files (ReadAnc) 

• Write version info (Write_LibVer, Write_AncVer) 

• Write requested ANC29 data 

• Write requested ANC32 data 

• Loop through available APID Types... 

If APID is input, ProcessAPID 

• Close all files and generate summaries (Main Wrap 
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19.4.1 PGE Core Routines 

PGE core routines are used exactly as defined in the Core PGE Section of this document. 

• Mainlnit 

• eCntrllnit 

• GetControl 

• OpenFiles 

• PrintCntl 

• WriteLibVer 

• ReadANC 

• Write_AncVer 

• MainWrap 
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Section 20 


Maker 


20.1 Overview 

Maker is a GSAS utility, but it does not use the functionality of the GSAS core PGE model. 

20.2 Function 

The Shuttle Radar Topography Mission (SRTM) was flown in February 2000. Interferometric 
Synthetic Aperture Radar data collected on that mission was used to produce a high resolution 
DEM of world land areas visible during the mission. This data was processed by the NASA 
Jet Propulsion Laboratory (JPL) into a product consisting of a set of 1 -degree square cells of 
elevations suitable for distribution and research. Cell granularity is 1200 increments per coor- 
dinate degree of latitude and longitude, with some degradation at the extreme latitude limits. 
Data is available between 60°N and 56°S latitudes. 

The purpose of the Maker program is to access and assimilate this data and to generate a set of 
pre-sorted, ICESat specific Track Files of SRTM DEM data which follow the fixed ICESat 
orbital tracks. The ultimate goal is to use to Maker's output Track Files quickly and efficiently 
to attach high resolution SRTM DEM data to GSAS Product Files. 

20.3 Design Approach 

Maker is a stand-alone utility that does not follow any of the GSAS prescriptions, libraries, or 
processing techniques discussed in previous chapters. It is essentially a single use utility, 
though it may be necessary to regenerate the track files if any initial conditions such as the 
fixed orbits are changed or the SRTM raw data has an update. Multiple files or a single track 
can be processed. Track Files produced by Maker have a complex series of four levels of self- 
referencing headers that can be used by software that reads the files to point directly to a 
desired elevation value if given an input location. 

20.4 Input and Output Files 

Table 20-1 lists the required input files for Maker. Appendix A of the “Interface Control Doc- 
ument Between ISIPS/ISF and CSR” can provide a description of the reference orbit file. 
Table 20-2 lists the output files created by Maker. 

20.5 Functions 

All functions utilized by Maker are contained within the source code. No additional library 
routines non-specific to FORTRAN are required. 
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Table 20-1 Maker Input Files 


File Spec 

Type 

Source 

Short 

Description 

“Control_Params” 

text 

user 

NAMELIST for- 
mat text file of 
parameters gov- 
erning program 
execution. 

“cell_names.txt” 

text 

user 

Comprehensive 
list of available 
cell files, derived 
from directory 
listing of files 

Orbit File 

Direct access 

GSAS Operations 

SCF ICESat Ref- 
erence Orbit file 

Cell Files 

Direct access 

USGS 

Set of direct 
access binary 
files of DEM ele- 
vations arranged 
in 1° x 1° cell 
according to lati- 
tude and longi- 
tude 


Table 20-2 Maker Output Files 


File Spec 

Type 

Destination 

Short 

Description 

“Pointings.txt” 

text 

Transient compu- 
tational file 

List of pointings 
along the path of 
the reference 
orbit being pro- 
cessed at the 
incremental gran- 
ularity of the cell 
files in latitude. 

“Swath.txt” 

text 

Transient compu- 
tational file 

List of pointings 
along the refer- 
ence orbit path 
for a given lati- 
tude and within a 
longitudinal limit 
of the central 
point. DEM val- 
ues are attached. 
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Table 20-2 Maker Output Files (Continued) 


File Spec 

Type 

Destination 

Short 

Description 

“Tracknnnn.DAT” 

Direct access 

Track Files 

Internally indexed 
file with multiple 
layers of head- 
ers containing 
DEM data. 

“P_ref_orb.txt” 

Text 

Diagnostic 

Text listing of ref- 
erence orbit file. 

Screen display 

Text 

Status and Diag- 
nostics 

Text listing of pro- 
gram progress. 


20.6 Functional Overview 

Processing for the Maker program is strictly linear. Each step makes use of the preceding 
event, whether it be successful opening of a file, reading of a file, or creation of a file. A fail- 
ure at any step terminates processing with an error message. The program performs the fol- 
lowing primary algorithmic steps to build a track file: 

• Get control parameters from namelist file. 

• Read reference orbit to obtain values of latitude and longitude from specified orbit 
track. 

• Identify a maximum list of SRTM cells crossed by track swath, utilizing the east/west 
bounds for any given time point, and based solely on possible track locations. 

• Compare the maximum list with the directory of available cells, and flag those that can 
be used. 

• Create the sequential pointings file for every potential central pointing. This set of 
pointings is continuous along the orbit, with no skips other than those for values 
deemed to be outside the useful range (e.g. high latitude). 

• Rewind the pointings file, for use as an input. 

• Create a sequential swath file containing an entry for every pointing. Use the saved 
coordinate data to compute each SRTM file name and internal location, and to then 
access the elevations along a swath line and attach them to the pointing data in the new 
swath file. 

• Rewind the swath file, for use as input. 

• Allocate a direct access file for the output track file. 

• Cycle through the swath file to accumulate statistics needed in the Level One and 
Level Two headers. 

• Create basic header data in the track file, and insert times in Level Three headers as 
placeholders instead of record numbers. 
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• Rewind the swath file, for use as input. 

• Cycle through the swath file data a second time, accumulate the records of elevations 
at the end of the existing track file, and insert locations for that data into existing 
header records. 
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Appendix A 

Processing Scenarios 


A.1 Scenarios 

All identified scenarios that will be eventually tested. 


Table A-1 Reprocessing Scenarios 


Scenario 

Primary Inputs 

Output 

Dependencies 

Processes 

End to end Lidar 

Level 0, ANC data 
(POD, Met, Cal file), 
Cntrl 

GLA02, 7- 
11, Meta- 
data 


LI A Atm ATBD, 
LIB Atm ATBD, 
L2 Atm ATBD, 
POD interp, Met 
interp 

End to end Altime- 
ter 

Level 0, POD, PAD, Met, 
Cal file, Cntrl 

GLA05,6,12 
-15, Meta- 
data 


LI A Altimeter 
ATBD, LIB 
Waveform ATBD, 
LIB Elevation, L2 
Elevation, POD, 
PAD, Geoloc 

Level 1 A Altimeter 

Level 0, Cal file, Cntrl 

GLA01, 

Metadata 


LI A Altimeter 
ATBD 

Level 1 B Waveform 

GLA01, POD, PAD, Cal 
file, ANC 19, 
surf_type_grid, Cntrl 

GLA05,Met 

adata 


LIB Waveform 
ATBD, POD, 
PAD, Geoloc, 
surfjype interp 

Level IB Elevation 

GLA05, GLA09&11 (if 
avail), tide coeff, geoid, 
ANC 12, DEM, Met 

GLA06, 

Metadata 

GLA09 and 11 
from GLAS_Atm 

Geoid, Tides, 
Geoloc, Met, 
DEM interp, Instr 
Range Cor (5) 
Reflectance, Atm 
Flag 

Level 2 Elevation 

GLA05, GLA06, 4 
Masks 

GLA12-15, 

Metadata 


Geoloc, Instr Cor 
Range Region- 
Specific Parame- 
ter Calculations 

Waveform Algo- 
rithm changes 
(standard, ice 
sheet, sea ice, 
ocean, land) 

GLA01, GLA05, Cal file 

GLA05, 

Metadata 

GLA06, GLA12- 
15(1 or all) 

Specific Wave- 
form algorithm 
process, Geolo- 
cation 

Replace POD and/ 
or PAD on GLA05 

GLA05, POD and/or 
POD 

GLA05, 

Metadata 


POD and/or PAD, 
Geolocation 
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Processing Scenarios 


Table A-1 Reprocessing Scenarios (Continued) 


Scenario 

Primary Inputs 

Output 

Dependencies 

Processes 

Replace PAD and/ 
or POD on GLA06 

GLA06, PAD and/or 
POD 

GLA06, 

Metadata 

GLA12-15 

PAD and/or POD, 
Geolocation 

Met changes, redo 
Met Cor 

GLA06, GLA12-15, Met 
file 

GLA06, 

GLA12-15, 

Metadata 


Met Interpola- 
tion, Geolocation 

Tides Change, 
redo tide cor 

GLA06, GLA12-15, tide 
coeff 

GLA06, 

GLA12-15, 

Metadata 


Tide algorithms, 
Geolocation 

Geoid changes 

GLA06, GIA12-15, 
Geoid 

GLA06, 

GLA12-15, 

Metadata 


Geoid 

Standard Instr Cor 
Changes 

GLA05, GLA06, GLAC- 
IS 

GLA06, 

GLA12-15, 

Metadata 


Standard Instr 
Cor Algorithm, 
Geolocation 

Region Spec Instr 
Cor Changes 

GLA05, GLA06, GLAC- 
IS 

GLA06, 

GLA12-15, 

Metadata 


Region Specific 
Instr Cor Algo- 
rithm 

Reflectance Algo- 
rithm changes 

GLA05, GLA06, GLAC- 
IS 

GLA06, 

GLA12-15, 

Metadata 


Reflectance 

ATBD 

Change GLA06 
based on WF Algo- 
rithm changing for 
GLA05 

GLA05, GLA06, GLAC- 
IS 

GLA06, 

GLA12-15, 

Metadata 


Range Instr Cor 
Calculation, Geo- 
location 

Replace PAD and/ 
or POD on GLAC- 
IS 

GLA12-15, PAD and/or 
POD 

GLA12-15, 

Metadata 


POD and or PAD, 
Geolocation 

Creation of GLA07 
BackScatter Pro- 
files 

GLA02, Met, POD, 400 
sec avg file 

GLA07, 

Metadata 


Interp POD, 

Interp Met, Molec 
BackScat Pro- 
files, Calib Coeff, 

1 064 BackScat 
Profiles, 532 
BackScat Profiles 

Creation of GLA08 
Aerosol Layers 

GLA07, Constants, 
GLA09 

GLA08 


1 and 4 sec 
BackScat aver- 
ages, PBL/Aero- 
sol <20 km 
layers, 20-40 km 
aerosol layers 
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Table A-1 Reprocessing Scenarios (Continued) 


Scenario 

Primary Inputs 

Output 

Dependencies 

Processes 

Creation of GLA09 
Cloud Layers 

GLA07, Constants 

GLA09 


1 and 4 sec 
BackScat aver- 
ages, Cloud Lay- 
ers 

Creation of GLA10 
Cross Section Pro- 
files and Creation 
of GLA11 Optical 
Depths 

GLA07, GLA08, GLA09, 
Constants 

GLA10, 

GLA11 


Cloud Optical 
Properties, Aero- 
sol Optical Prop- 
erties, 1 and 4 
sec BackScat 
averages 
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Appendix B 

Makefiles and Libraries 


Developers are “strongly” encouraged to use standard GSAS libraries and makefiles. GSAS 
libraries leverage existing code to speed development and ease maintenance. Makefiles ensure 
common compiler flags and allow developers to deliver their software as part of a general 
GSAS delivery. 

B.1 Compilation 

Note: This documentation is specific to the GLAS development environment. It assumes that 
the core directory of the GLAS software is located at “/glas/vob 

B.1 .1 To compile the whole distribution 

cd /glas/vob/src 
make 

B.1 .2 To compile only the libraries 

cd /glas/vob/src 
make libs 

B.1 .3 To recompile a library in debug mode 

cd /glas/vob/ src/ library _directory 
make debug 

B.1 .4 To recompile a library in optimized mode 

cd /glas/vob/src/ library- directory 
make fast 

B.1 .5 To compile a specific executable 

(requires that the libraries are compiled beforehand) 

cd /glas/vob/src/ executabl e_directory 
make 

B.1 .6 To compile a specific executable in debug mode 

(requires that the libraries are compiled beforehand) 

cd /glas/vob/src/ executabl e_directory 
make debug 

B.1 .7 To compile a specific executable in optimized mode 

(requires that the libraries are compiled beforehand) 

cd /glas/vob/src/ executabl e_directory 
make fast 
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B.2 Using Libraries 

This section details the use of libraries, both at development and run time stages. 

B.2.1 Development 

To use a library, you need to include the path and the library name in your Makefde. The fol- 
lowing example shows how to use the platform_lib (which is stored in the /glas/vob/src/lib 
directory) to compile a test program: 

f 90 test. f 90 -L/glas/vob/src/lib -lplatform -otest 

The next example show how to use the fde and anc libraries as well. (A side note: By unix 
convention the full fdenames are libplatform.sl, libfile.sl, and libanc.sl, however when they 
are specified with the -1 argument on the compile line, the “lib” and “.si” parts are dropped). 

f 90 test. f 90 -L/glas/vob/src/lib -lplatform -lane -lfile -otest 

ORDER IS IMPORTANT. See Foundation Libraries section of this document to verify that 
the libraries are specified in the correct order on the compile line. 

B.2.2 Runtime 

GSAS libraries are dynamically-linked shared libraries. What this means is that the libraries 
are not statically linked with executables, but dynamically linked on demand at runtime. With 
this in mind, it is important that the executable be able to determine the location of the librar- 
ies at runtime. During compilation, the location of the libraries is stored in the executable 
code. If the executable is moved, and the location is relative, the libraries will not be found 
upon execution. In this case, a developer should use the following procedure to allow execut- 
ables to link to dynamic libraries, no matter their location. 

chatr +s enable <executable_name> 
setenv SHLIB_PATH <pathname to libraries> 

This procedure tells the executable to use the SHLIBPATH environmental variable to find its 
libraries, then sets that variable to the path of the shared libraries. 

The other way of handling this is to link the libraries into the current directory. The executable 
is set to look in the current directories first for its libraries. 

B.3 Some Development Hints 

• If you want to use the GLAS libraries, simply compile them (as above) and include the 
appropriate lines in your makefile (again, as above). 

• As long as you model the Makefile for your executable after that of the GLAS PGEs, 
you will be using shared libraries and will not need to recompile your executable after 
recompiling a library - unless global data structures or subroutine arguments are 
changed. 

• If you would like to debug the routines in a specific library, cd to that directory and do 
a make clean; make debug. Next time you run your executable (you don’t have to 
recompile it), it will run with the debug version of the library. 
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• Using the -g and +check=all flags (included with make debug) is a good idea during 
testing. 

• If you want to get fancy and create a custom makefde for a special purpose, simply use 
another name for the makefile and use make -f mymakefile. 

• You may add custom options to the standard makefiles by putting the options on the 
gF90_AUX_FLAGS line. For example, if you wish to define a custom flag 
(DEBUG TIME) for debugging purposes, define it as follows: 

gF90_AUX_FLAGS= -DDEBUG_TIME 

B.4 Makefile Details 

This is an attempt to explain how GLAS makefiles work. This assumes the reader is some- 
what familiar with the GLAS VOB layout. 

B.5 Types of Makefiles 

There are different types of makefiles. This section identifies each. 

B.5.1 The Main Makefile 

This makefile is located at /glas/vob/Makefile. This makefile builds all GSAS software and 
installs the binaries and libs in the /glas/vob/bin and /glas/vob/lib directories. This makefile is 
primarily used during production, not development. Developers should always use/link to the 
binaries and libraries within the src directory, not those in the /bin and /lib directories since the 
top-level makefile is the only one which populates such directories. 

B.5.2 The src Makefile 

This makefile is located at /glas/vob/src/Makefile. It is the main development makefile which 
will recursively build all GSAS deliverable software. There are options to: 

• build all deliverable GLAS Libraries (make libs) 

• build all deliverable GLAS binaries (make progs) 

• build all deliverable Libraries and binaries (make all) -the default 

• build all deliverable Libraries and binaries in debug mode (make debug) 

• build all deliverable Libraries and binaries in optimization mode (make fast) 

• clean up all object code and module files (make clean) 

B.5.3 Library Makefiles 

These makefiles are located at src/common_libs/*/Makefile. There are options to: 

• Compile library source and install library (make) 

• Compile library source in debug mode and install library (make debug) 

• Compile library source in optimization mode and install library (make fast) 
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The libraries are derived objects and installed into /glas/vob/src/lib 

B.5.4 Subsystem Makefiles 

These makefiles are located at /glas/vob/src/*_lib/Makefile (where * = 11a, atm, elev, wf) 

• Compile library source and install library (make) 

• Compile library source in debug mode and install library (make debug) 

• Compile library source in optimization mode and install library (make fast) 

The libraries are derived objects and installed into /glas/vob/src/lib. When installed, the librar- 
ies are stored in /glas/vob/lib. 

B.5.5 Exec makefiles 

These makefdes are located in the directory of each delivered executable: src/GLAS_Ll A/ 
Makefile, src/GLAS_LOproc/Makefile, etc. There are options to: 

• Compile binary source (make) 

• Compile binary source in debug mode (make debug) 

• Compile binary source in optimization mode (make fast) 

The executables are derived objects and installed into /glas/vob/bin. 

B.6 A Sample Heavily-Commented Makefile 

# NAME: Makefile 

# 

# FUNCTION: Makefile for GLAS_Exec 

# 

# FILES ACCESSED: See TARGETS definition. 

# ALL DIRECTORY SPECIFICATIONS SHOULD BE RELATIVE , NOT ABSOLUTE , 
PATHS ! ! 

# 

# COMMENTS: None. 

# 

# HISTORY: 

# 


# 

1998 

December 

18, 

JLee , 

Initial 

Version 

# 

1999 

January 

14, 

JLee , 

Ported ' 

to HP 

# 

1999 

October 

18, 

JLee 

Removed 

default DEBUG, removed recursion 

# 

1999 

October 

24, 

JLee 

Set the 

bit to do SHLIB_PATH 


# 


# Set filepaths 

# 

# PATHLVL is the path you use to get to /glas/vob/src , but it should 

# be a relative path so that we can compile outside the VOB . 

# 


PATHLVL = . . 

# 

# UTILDIR is where the GLAS makefile includes can be found. These files 

# contain settings specific to GLAS Makefiles. 

# /glas/vob/cc_util is the actual path. 

# 

UTILDIR=$ (PATHLVL) / . . /cc_util 
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# 

# Include Standard GLAS Definitions 

# 

include $ (UTILDIR) /make_def s . $ (BRAND) 
include $ (UTILDIR) /make_def s . incl 
# 

# Define libraries we will need. They are located in /glas/vob/src/lib . 

# This path is pre-defined (relatively) in the GLAS include files. 

# The actual filename for -lwf is libwf.sl, -file is libfile.sl 

# 

LIBS= -111a -latm -lwf -lelev -lprod -lfile -ltime -lane -lcntrl \ 

-lerr -lplatform 

# 

# Define the Production directory where we will copy the binary upon 

# creating a production build 

# 

PRODDIR=$ ( PATHLVL / . . /bin) 

# 

# Define the target binary 

# 

TARGET = GL AS_Exe c 

# 

# Define the objects will are needed by the Target 

# 

OBJECTS^ \ 

CntlDef s_mod . o fCntl_mod.o eCntl_mod.o \ 

MainInit_mod . o ReadData_mod . o GetControl_mod . o \ 

CloseFiles_mod . o OpenFiles_mod . o WriteLlA_mod . o WriteWF_mod . o \ 
WriteAtm_mod . o WriteElev_mod . o MainWrap_mod . o \ 

ReadAnc_mod . o LlAMgr_mod . o ElevMgr_mod . o WFMgr_mod . o AtmMgr_mod . o \ 
vers_exec_mod . o GLAS_Exec . o 

# 

# Custom Rules 

# 

gF 9 0 _AUX_ F LAG S = 

# 

# Make our Target by default 

# 

all: $ (TARGET) 

# 

# TARGET , LIBS and OBJECTS are defined in this makefile. 

# LINK_EXE . f 9 0 and FFLAGS are defined in the GLAS includes. 

# chart +s enable allows the executable to use the SHLIB_PATH to 

# look for its shared libraries. 

# 

$ (TARGET): $ (OBJECTS) Makefile 

$ (LINK_EXE. f 90) $ (FFLAGS) -o $ (TARGET) $ (OBJECTS) $ (LIBS) ; \ 

chatr +s enable $ (TARGET) 

# 

# Include Standard GLAS Dependencies 

# 

include $ (UTILDIR) /make_depends . incl 

# 

# End of MakeFile 

# 
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A2P 

ALT 

ANCxx 

APID 

ATBD 

ATM 

CCB 

ClearCase 

CR 

DAAC 

DEM 

DFD 

DLT 

EDOS 

EDS 

ELEV 

EOC 

EOS 

EOSDIS 

GB 

GDS 

GLAS 

GLAxx 

GLOP 

GPS 

GSAS 

GSFC 

GSFC/WFF 


Algorithm-to-Product Conversion 

Altimeter or Altimetry, also designation for the EOS-Altimeter spacecraft series 

GLAS Ancillary Data Files 

GLAS Level-0 Data file 

Algorithm Theoretical Basis Document 

Atmosphere 

Change Control Board 

GSAS version tracking software 

Change Request 

Distributed Active Archive Center 

Digital Elevation Model 

Data Flow Diagram 

Digital Linear Tape 

EOS Data and Operations System 

Expedited Data Set 

Elevation 

EOS Operating Center 

NASA Earth Observing System Mission Program 
Earth Observing System Data and Information System 
Gigabyte 

GLAS Ground Data System 

Geoscience Laser Altimeter System instrument or investigation 

GLAS Science Data Product Files 

GLAS Level-0 PGE (correctly called GLAS_LOproc) 

Global Positioning System 
GLAS Science Algorithm Software 

NASA Goddard Space Flight Center at Greenbelt, Maryland 

NASA Goddard Space Flight Center/Wallops Flight Facility at Wallops Island, 
Virginia 
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HDF 

Hierarchal Data Format 

HDF-EOS 

EOS-specific Hierarcial Data Format 

l-SIPS 

Icesat Science Investigator Led Processing System 

I/O 

Input/Output 

ICESAT 

Ice, Cloud and Land Elevation Satellite 

ID 

Identification 

ID 

Identification 

IEEE 

Institute for Electronics and Electrical Engineering 

ISF 

Instrument Support Facility 

1ST 

Instrument Star Tracker 

KB 

Kilobyte 

JPL 

Jet Propulsion Laboratory 

L0 

Level 0 

L1A 

Level-1 A 

LIB 

Level-1 B 

L2 

Level-2 

LASER 

Light Amplification by Stimulated Emission of Radiation 

LASER 

Light Amplification by Stimulated Emission of Radiation 

LIDAR 

Light Detection and Ranging 

LIDAR 

Light Detection and Ranging 

LPA 

Laser Pointing Array 

LRS 

Laser Reference System 

MB 

Megabyte 

MET 

(context sensitive) Mission Elapsed Time or Meteorological 

N/A or NA 

Not (/) Applicable 

NASA 

National Aeronautics and Space Administration 

NOAA 

National Oceanic and Atmospheric Administration 

NOSE 

Nominal Orbital Spatial Extent 

P2A 

Product-to-Algorithm Conversion 

PAD 

Precision Attitude Determination 

PDF 

Portable Document Format 

PDS 

Production Data Set 
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PGE 

Product Generation Executable 

POD 

Precision Orbit Determination 

POD 

Precision Orbit Determination 

PR 

Problem Report 

QA 

Quality Assessment 

QAP 

Quality Assessment Processing 

SC 

Structure Chart 

SCF 

Science Computing Facility 

SDMP 

Science Data Management Plan 

SDMS 

Scheduling and Data Management System 

SDP 

Standard Data Products 

SRS 

Stellar Reference System 

SRTM 

Shuttle Radar Topography Mission 

SSMP 

Science Software Management Plan 

SSRF 

Science Software Requirements Document 

TBD 

to be determined, to be done, or to be developed 

UNIX 

the operating system jointly developed by the AT&T Bell Laboratories and the 
University of California-Berkeley System Division 

UTC 

Universal Time Correlation 

WF 

Waveform 


March 2013 


Page AB-3 


Version 6.0 



The GLAS Science Algorithm Software Detailed Design Document 


Abbreviations & Acronyms 


Version 6.0 


Page AB-4 


March 2013 



Glossary 


aggregate 


array 


file 


header 


item 


label 


Level 0 


Level 1A 


A collection, assemblage, or grouping of distinct data parts together to make a 
whole. It is generally used to indicate the grouping of GLAS data items, 
arrays, elements, and EOS parameters into a data record. For example, the 
collection of Level 1 B EOS Data Parameters gathered to form a one-second 
Level 1 B data record. It could be used to represent groupings of various 
GLAS data entities such as data items aggregated as an array, data items and 
arrays aggregated into a GLAS Data Element, GLAS Data Elements aggre- 
gated as an EOS Data Parameter, or EOS Data Parameters aggregated into a 
Data Product record. 

An ordered arrangement of homogenous data items that may either be syn- 
chronous or asynchronous. An array of data items usually implies the ability to 
access individual data items or members of the array by an index. An array of 
GLAS data items might represent the three coordinates of a georeference 
location, a collection of values at a rate, or a collection of values describing an 
altimeter waveform. 

A collection of data stored as records and terminated by a physical or logical 
end-of-file (EOF) marker. The term usually applies to the collection within a 
storage device or storage media such as a disk file or a tape file. Loosely 
employed it is used to indicate a collection of GLAS data records without a 
standard label. For the Level 1 A Data Product, the file would constitute the 
collection of one-second Level 1 A data records generated in the SDPS work- 
ing storage for a single pass. 

A text and/or binary label or information record, record set, or block, prefacing 
a data record, record set, or a file. A header usually contains identifying or 
descriptive information, and may sometimes be embedded within a record 
rather than attached as a prefix. 

Specifically, a data item. A discrete, non-decomposable unit of data, usually a 
single word or value in a data record, or a single value from a data array. The 
representation of a single GLAS data value within a data array or a GLAS Data 
Element. 

The text and/or binary information records, record set, block, header, or head- 
ers prefacing a data file or linked to a data file sufficient to form a labeled data 
product. A standard label may imply a standard data product. A label may 
consist of a single header as well as multiple headers and markers depending 
on the defining authority. 

The level designation applied to an EOS data product that consists of raw 
instrument data, recorded at the original resolution, in time order, with any 
duplicate or redundant data packets removed. 

The level designation applied to an EOS data product that consists of recon- 
structed, unprocessed Level 0 instrument data, recorded at the full resolution 
with time referenced data records, in time order. The data are annotated with 
ancillary information including radiometric and geometric calibration coeffi- 
cients, and georeferencing parameter data (i.e., ephemeris data). The 
included, computed coefficients and parameter data have not however been 
applied to correct the Level 0 instrument data contents. 
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Level IB 


Level 2 


Level 3 


Level 4 


metadata 


orbit 


model 

module 


parameter 


pass 


PDL 


process 


The level designation applied to an EOS data product that consists of Level 1 A 
data that have been radiometrically corrected, processed from raw data into 
sensor data units, and have been geolocated according to applied georefer- 
encing data. 

The level designation applied to an EOS data product that consists of derived 
geophysical data values, recorded at the same resolution, time order, and geo- 
reference location as the Level 1A or Level IB data. 

The level designation applied to an EOS data product that consists of geo- 
physical data values derived from Level 1 or Level 2 data, recorded at a tem- 
porally or spatially resampled resolution. 

The level designation applied to an EOS data product that consists of data 
from modeled output or resultant analysis of lower level data that are not 
directly derived by the GLAS instrument and supplemental sensors. 

The textual information supplied as supplemental, descriptive information to a 
data product. It may consist of fixed or variable length records of ASCII data 
describing files, records, parameters, elements, items, formats, etc., that may 
serve as catalog, data base, keyword/value, header, or label data. This data 
may be parsable and searchable by some tool or utility program. 

The passage of time and spacecraft travel signifying a complete journey 
around a celestial or terrestrial body. For GLAS and the EOS ALT-L spacecraft 
each orbit starts at the time when the spacecraft is on the equator traveling 
toward the North Pole, continues through the equator crossing as the space- 
craft ground track moves toward the South Pole, and terminates when the 
spacecraft has reached the equator moving northward from the South Polar 
region. 

A graphical representation of a system. 

A collection of program statements with four basic attributes: input and output, 
function, mechanics and internal data. 

Specifically, an EOS Data Parameter. This is a defining, controlling, or con- 
straining data unit associated with a EOS science community approved algo- 
rithm. It is identified by an EOS Parameter Number and Parameter Name. An 
EOS Data Parameter within the GLAS Data Product is composed of one or 
more GLAS Data Elements 

A sub-segment of an orbit, it may consist of the ascending or descending por- 
tion of an orbit (e.g., a descending pass would consist of the ground track seg- 
ment beginning with the northernmost point of travel through the following 
southernmost point of travel), or the segment above or below the equator; for 
GLAS the pass is identified as either the northern or southern hemisphere por- 
tion of the ground track on any orbit 

Program Design Language (Pseudocode). A language tool used for module 
programming and specification. It is at a higher level than any existing compil- 
able language. 

An activity on a dataflow diagram that transforms input data flow(s) into output 
data flow(s). 
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product 


program 

record 

Scenario 

Standard Data 
Product 


State Transition 
Diagram 

Stub 

Structure Chart 

Structured Design 

Subroutine 

variable 


Specifically, the Data Product or the EOS Data Product. This is implicitly the 
labeled data product or the data product as produced by software on the 
SDPS or SCF. A GLAS data product refers to the data file or record collection 
either prefaced with a product label or standard formatted data label or linked 
to a product label or standard formatted data label file. Loosely used, it may 
indicate a single pass file aggregation, or the entire set of product files con- 
tained in a data repository. 

The smallest set of computer instructions that can be executed as a stand- 
alone unit 

A specific organization or aggregate of data items. It represents the collection 
of EOS Data Parameters within a given time interval, such as a one-second 
data record. It is the first level decomposition of a product file. 

A single execution path for a process. 

Specifically, a GLAS Standard Data Product. It represents an EOS ALT-L/ 
GLAS Data Product produced on the EOSDIS SDPS for GLAS data product 
generation or within the GLAS Science Computing Facility using EOS science 
community approved algorithms. It is routinely produced and is intended to be 
archived in the EOSDIS data repository for EOS user community-wide access 
and retrieval. 

Graphical representation of one or more scenarios. 


(alias dummy module) a primitive implementation of a subordinate module, 
which is normally used in the top-down testing of superordinate (higher) mod- 
ules. 

A graphical tool for depicting the partitioning of a system into modules, the 
hierarchy and organization of those modules, and the communication inter- 
faces between the modules. 

The development of a blueprint of a computer system solution to a problem, 
having the same components and interrelationships amount the components 
as the original problem has. 

A program that is called by another program 

Usually a reference in a computer program to a storage location, i.e. , a place 
to contain or hold the value of a data item. 


March 2013 


Page GL-3 


Version 6.0 



The GLAS Science Algorithm Software Detailed Design Document 


Glossary 


Version 6.0 


Page GL-4 


March 2013 



